Audytowanie baz danych w sieci grid Część 2: Obserwacje po wdrożeniu

W poprzednim poście dla tej serii mówiłem o tym, jak podeszliśmy do zbierania wymagań dla tego projektu, jak podjęliśmy decyzję o tym, jakiego narzędzia użyć i jak zaplanowaliśmy wdrożenie, aby uniknąć przerw w działaniu usług. Zgodnie z obietnicą, ten post koncentruje się na obserwacjach po wdrożeniu i na tym, jakie czynniki sprawiły, że ta historia okazała się dla nas udana.

Przygotowane deklaracje i filtrowanie klas poleceń

Nasz początkowy projekt dla tego projektu miał na celu wykorzystanie funkcji wtyczki percona, która pozwala filtrować emitowane zdarzenia, aby użyć listy poleceń uwzględnionych lub poleceń wykluczonych, aby ograniczyć zakres do tego, czego faktycznie potrzebujemy do audytu.

Funkcja ta polega na tym, że wtyczka oznacza każde wykryte polecenie sql klasą opartą na liście właściwej dla mysql, a następnie decyduje w warstwie wyjściowej, czy wykryta klasa poleceń powinna zostać pominięta, czy wyemitowana.

Dlatego napisaliśmy wstępny plan, aby wykorzystać funkcję audit_log_exclude_commands do wykluczenia wszelkich poleceń sql, które nie powodowały zapisów ani zmian w danych wiersza. Wybraliśmy listę wykluczeń, ponieważ uważaliśmy, że lista włączeń niesie ze sobą ryzyko pominięcia jakichkolwiek klas poleceń w zakresie i może stać się przyczyną luk w naszych dziennikach kontroli.

Jednak w pierwszym testowanym klastrze zauważyliśmy, że wszystkie kontrolowane polecenia były klasyfikowane jako błędy , mimo że było jasne, że te instrukcje działały pomyślnie, a w przypadku zmiany danych również to robiły. Zauważyliśmy również, że wszystkie zapytania były wysyłane do scentralizowanego serwera syslog, niezależnie od listy wykluczeń, która wydaje się być skorelowana z tą klasyfikacją błędów.

Oznaczało to, że w Elasticsearch przechowywaliśmy znacznie więcej zdarzeń, niż faktycznie potrzebowaliśmy, co z pewnością wpłynie na naszą zdolność do analizy i wykrywania błędnych zachowań w odpowiednim czasie. We współpracy z zespołem ds. bezpieczeństwa zdecydowaliśmy się poinformować Perconę o problemie za pomocą narzędzia do śledzenia błędów, ale także przenieść filtrowanie oparte na poleceniach do centralnej warstwy dziennika systemowego.

Jak wszystko w inżynierii, kompromis polegał na przesłaniu większej ilości danych przez warstwę sieciową bazy danych i zwiększeniu złożoności filtrowania w scentralizowanej warstwie dziennika systemowego, co w zamian sprawiło, że nasze potrzeby w zakresie elastycznego skalowania wyszukiwania były łatwiejsze w zarządzaniu, a konfiguracja po stronie bazy danych prostsza.

Występ

Jedną z najważniejszych decyzji w tym projekcie, która zaoszczędziła nam wiele bólu serca, jest decyzja o użyciu funkcji rsyslog do przechwytywania i wysyłania tych dzienników do scentralizowanego serwera syslog.

Ale nic nie jest bez zalet i wad.

Ta decyzja oznaczała, że ​​czas pracy oddzielnego systemu i niezawodność stosu sieciowego pomiędzy nimi stały się kluczowe dla zapewnienia SLA, którego potrzebowaliśmy, aby dać naszemu zespołowi audytowemu zaufanie do tego rozwiązania audytowego.

Dla tych, którzy nie chcą iść na kompromis i muszą zachować odpowiedzialność za trwałość dzienników audytu w stosie DB, polecam użycie obsługi FILE we wtyczce audytu, a następnie użycie lokalnego logstash do pobrania logów i przekazania ich do ich systemu analizy wybór.

Ten drugi wybór oznacza znacznie więcej procesorów IOP dysku zużywanych poza procesem bazy danych i zajmowanych przez wtyczkę audytu i logstash, a także oznacza, że ​​musisz ostrożnie zrównoważyć przestrzeń dyskową na swoich instancjach między plikami tabel bazy danych, dziennikami operacyjnymi i audytem dzienniki wtyczek. Ważenie opcji zależy wyłącznie od tego, które z nich jest łatwiejsze w obsłudze/akceptowalne przez firmę, ale mimo to masz wybór.

W naszym przypadku wybór rsyslog okazał się najmniejszy wpływ na nasze bardziej obciążone bazy danych, osiągając około 5400 transakcji na sekundę, podczas normalnych operacji nie widzieliśmy żadnego wpływu na wydajność. Wtyczka audytu trudziła się, wysyłając swoje zdarzenia bez wpływu na wydajność bazy danych. Wszystko dlatego, że wybraliśmy architekturę, która unikała korzystania z operacji dyskowych po stronie bazy danych.

Wcześniejsze decyzje się opłacają

Jedną z pierwszych obaw, jakie mieliśmy, kiedy rozpoczynaliśmy ten projekt, był jego wpływ na wydajność. Jeden z objętych zakresem klastrów baz danych był bardzo pracowity, a jego aplikacje są wrażliwe na opóźnienia, więc musieliśmy upewnić się, że śledzimy wskaźniki wydajności, takie jak transakcje na sekundę, wykorzystanie dysku i procesora, aby porównać liczby po wdrożeniu wtyczki i zobacz, jaka jest za to kara.

Miłą niespodzianką było to, że nie ponieśliśmy dużej kary w normalnych operacjach. Jak wspomniano wcześniej, ponieważ zdecydowaliśmy się użyć programu obsługi SYSLOG, oznaczało to, że zwykle nie musieliśmy wykorzystywać żadnej pojemności dysku lokalnego do śledzenia tych zdarzeń audytu.

Ale nie chcieliśmy też planować wyłącznie w oparciu o czasy „normalnej pracy”.

Musieliśmy również wiedzieć, że gdy rsyslog musi wrócić do lokalnych plików buforowania, zdarzenia te nie łączą się z usługami wpływającymi na przestoje dla bardziej krytycznych klastrów DB. Testując zachowanie buforowania rsyslog pod ścisłą obserwacją w środowisku produkcyjnym, zdaliśmy sobie sprawę, że ostatnie kilka lat pracy nad funkcjonalnym fragmentowaniem naszych baz danych przyniosło nam nieplanowane korzyści wynikające z dużej liczby operacji we/wy dysku w celu absorpcji zdarzeń, takich jak buforowanie rsyslog na dysk, a następnie potrzebne do ponownego wysłania. wszystkie te wydarzenia.

Zdecydowanie zauważyliśmy wzrost wykorzystania dysku podczas tych zdarzeń, ale nigdy nie doprowadziło to instancji bazy danych do stanu krytycznego ani nie wpłynęło na aktywność klientów.

Kompromisy

Jak wszystko w inżynierii oprogramowania, zawsze są kompromisy. W tym projekcie rozważaliśmy metodę dostarczania logów, która byłaby bardziej niezawodna i miała mniejszy potencjał do utraty logów. Wymagałoby to zapisania dzienników na dysku, a następnie użycia czegoś takiego jak logstash do przetworzenia i wysłania ich do miejsc docelowych analizy, z których może skorzystać zespół ds. bezpieczeństwa.

Oznaczałoby to jednak znaczne zużycie procesorów IOP dysku po stronie bazy danych, o czym wiedzieliśmy, że może potencjalnie wpłynąć na jakość obsługi połączeń z tymi bazami danych skierowanych do klientów.

Zdecydowaliśmy, że nasze potrzeby biznesowe zostaną w wystarczającym stopniu zaspokojone przez elastyczne rejestrowanie w rsyslog, buforowanie o rozsądnej wielkości i używanie protokołu TCP do wysyłania zdarzeń do naszego stosu monitorowania dzienników. Jak wszystko w życiu, nic nie jest wieczne. Zdajemy sobie sprawę, że w przyszłości może być konieczna zmiana tej decyzji.

Wreszcie

Ten projekt, obejmujący pół tuzina klastrów i dużą liczbę instancji, został ukończony w ciągu jednego kwartału, podczas gdy zespół operacyjny DB nadal utrzymywał światło w wciąż szybko rozwijającej się działalności. Nie mogłoby się to wydarzyć bez ścisłej współpracy między DBE a zespołem ds. bezpieczeństwa i bez silnego zarządzania produktami, które utrzymywało ograniczony zakres i było znane z tego, że wszyscy zwracamy uwagę na ostateczny cel, jakim jest zwiększenie bezpieczeństwa naszej działalności.