Istnieje coraz więcej świetnych systemów monitorowania wydajności baz danych. Ostatnio do bardziej tradycyjnych rozwiązań lokalnych dołączyły rozwiązania typu oprogramowanie jako usługa (SaaS).
W tym blogu porównano typową architekturę rozwiązania lokalnego z architekturą rozwiązania SaaS. Oczywiście komponenty będą się różnić pod względem nazwy i struktury w zależności od dostawcy, ale kluczowe koncepcje omawiane tutaj będą reprezentowane w takiej czy innej formie.
Różnice między rozwiązaniami lokalnymi a rozwiązaniami SaaS
Ogólnie rzecz biorąc, oto niektóre z kluczowych elementów każdego rozwiązania:
Tradycyjne rozwiązanie lokalne
- Proces zbierania danych.
- Repozytorium wydajności krótkoterminowej [diagnostyka].
- Długoterminowe repozytorium analiz/raportów.
- Klient Windows lub przeglądarki.
- Wszelka infrastruktura przełączania awaryjnego wymagana dla infrastruktury monitorowania.
Rozwiązanie SaaS
- Proces zbierania danych (dla celów lokalnych).
- Klient przeglądarki.
- Aplikacja mobilna.
- Dostawca SaaS zarządza aplikacją i przechowywaniem danych zaplecza.
Pamiętaj, że nazwy różnych składników będą się różnić w zależności od rozwiązania. W niektórych przypadkach funkcjonalność może być podzielona na wiele usług lub źródeł danych.
Rozwiązania lokalne
Proces zbierania danych
Moduł gromadzący dane jest zazwyczaj lokalną usługą bez agenta, która zbiera dane z dowolnego lokalnie monitorowanego punktu końcowego. Ten proces koordynuje sposób i czas zbierania danych. Powinien być w stanie zbierać dane z różnymi częstotliwościami, aby zrównoważyć potrzebę większej ilości szczegółów z wpływem na monitorowane obciążenie pracą. Częstotliwości zbierania i progi alertów powinny być wstępnie skonfigurowane dla każdej metryki.
Każdy będzie miał „hałaśliwą” instancję, która nie spełnia standardowych progów. Może to spowodować wiele fałszywych alarmów. Aby sobie z tym poradzić, system powinien mieć możliwość tworzenia reguł na poziomie instancji, aby poradzić sobie z wyjątkowymi okolicznościami. Pozwala to uniknąć „zmęczenia alarmem” spowodowanego fałszywymi alarmami.
W niektórych przypadkach ta usługa organizuje również alerty i powiadomienia. W dużych organizacjach z setkami monitorowanych instancji może być konieczne zrównoważenie obciążenia poprzez „federację” wielu kolektorów danych. Federacja synchronizuje kolekcje i konfigurację w rozproszonym systemie.
Repozytorium diagnostyki krótkoterminowej
Tutaj przechowywane są szczegółowe dane. Obejmuje to dane z DMV, plików dziennika, zdarzeń XEvent i innych źródeł danych programu SQL Server. Należy unikać źródeł, które mogą wywierać presję na monitorowane instancje, np. większość śladów nie nadaje się do monitorowania w czasie rzeczywistym.
Ponieważ częstotliwości zbierania mogą być tak częste, jak co sekundę, a zbierane są większe porcje danych, takie jak TSQL i plany, to repozytorium może szybko się rozrosnąć. W rezultacie większość systemów zazwyczaj ogranicza historię od tygodnia do miesiąca (te ograniczenia nie dotyczą rozwiązania SaaS). To repozytorium ma charakter wysoce transakcyjny.
Repozytorium raportów/analiz długoterminowych
Pod koniec wstępnie zdefiniowanego czasu te szczegółowe dane są agregowane i przechowywane w repozytorium raportów na potrzeby analiz wysokiego poziomu i tworzenia trendów. Ilość zachowanych szczegółów będzie miała znaczący wpływ na ostateczny rozmiar tego repozytorium i moc obliczeniową, której można racjonalnie oczekiwać, że użytkownik udostępni ją do analizy. To może się znacznie różnić w zależności od rozwiązania. Rozwiązania obsługujące głębszą analizę będą miały architektury wspierające i mogą wykorzystywać architektury OLAP w celu ułatwienia analizy wielowymiarowej.
Skalowanie lokalnego rozwiązania do monitorowania
Bardziej wyrafinowane rozwiązania zostaną zaprojektowane w celu ułatwienia rozproszonej architektury kluczowych komponentów w celu obsługi skali. Usługa gromadzenia danych będzie miała górną liczbę monitorowanych połączeń, którą może obsługiwać. Po osiągnięciu tego limitu dodatkowy zbieracz danych powinien zostać „sfederowany”, aby koordynować gromadzenie danych i organizować przechowywanie danych.
Same repozytoria danych o wydajności mogą współużytkować jedną instancję lub mogą być rozłożone na kilka instancji w celu obsługi skalowania. Wymagana przez nich pamięć będzie wprost proporcjonalna do liczby monitorowanych połączeń i ilości przechowywanych danych. Struktura i architektura repozytorium analitycznego również wpłynie na całkowitą pojemność.
Doświadczenie użytkownika
Większość narzędzi lokalnych ma interfejs systemu Windows. Niektóre mają interfejsy przeglądarki oparte na wdrożeniu hostowanym lokalnie. Zdalny dostęp do nich może być zawiły i zazwyczaj wymaga VPN. Rzadko obsługują aplikacje mobilne.
Wysoka dostępność
Oprogramowanie monitorujące, które monitoruje obciążenia o znaczeniu krytycznym, musi być samo w sobie odporne. Należy zapewnić obsługę sytuacji katastroficznych, które mogą spowodować wyłączenie struktury monitorowania. Należy to również rozważyć z perspektywy architektury i kosztów.
Rozwiązania SaaS
Proces zbierania danych
Chociaż oferta SaaS jest głównie hostowana, często będzie utrzymywać lokalny moduł gromadzący dane dla obciążeń lokalnych. Pomaga to rozwiązać ograniczenia wydajności i bezpieczeństwa. W ten sposób wszelkie połączenia na poziomie instancji są nawiązywane za pośrednictwem lokalnego kolektora, który następnie przekazuje dane dotyczące wydajności monitorowanej bazy danych do usługi przychodzącej do chmury. Wszystkie dane powinny być szyfrowane podczas przesyłania.
Repozytoria diagnostyki i raportowania/analizy
Dobrą wiadomością jest to, że dostawca SaaS obsługuje wszystkie Twoje dane. Nie musisz się martwić o uruchamianie instancji dla repozytoriów diagnostycznych, raportowanie repozytoriów, opróżnianie repozytorium diagnostycznego ani wiele innych problemów związanych z wdrożeniem lokalnym.
Rozwiązania hostowane będą opierać się na różnych strategiach przechowywania w zapleczu, aby ułatwić odpowiednie połączenie działań transakcyjnych i analitycznych. Mogą korzystać z zasobów w chmurze, aby obsługiwać większe ilości danych i wymagane przetwarzanie wymagane do analizy; np. Spotlight Cloud przechowuje szczegółowe dane z jednego roku. Dzięki temu możesz nie tylko zgłosić rok wstecz, ale także odtworzyć swoje obciążenie pracą z poprzedniego roku. To naprawdę potężna funkcja.
Rozwiązanie SaaS do monitorowania wydajności bazy danych może wykorzystywać różne strategie pamięci masowej zaplecza nie tylko w celu dostosowania do bardziej transakcyjnego charakteru diagnostyki i monitorowania, ale także w celu ułatwienia intensywnego przetwarzania danych związanego z analizą długoterminową. Dostawca SaaS może czerpać znaczne korzyści skali, aby korzystać z dużo wydajniejszej infrastruktury, która byłaby do dyspozycji poszczególnych organizacji.
Jak skalować rozwiązanie SaaS
Za skalowanie rozwiązania SaaS odpowiada dostawca, a nie użytkownik. Każde rozwiązanie SaaS do monitorowania wydajności bazy danych musi być skalowane od pierwszego dnia, w wyniku czego radzi sobie z skalowaniem bez problemu.
Doświadczenie użytkownika
Aplikacje SaaS będą domyślnie korzystać z przeglądarki Ux, a wiele z nich będzie miało również wszechstronne aplikacje mobilne. Ułatwia to rozproszone i zdalne zespoły.
Bezpieczeństwo i zgodność
Większość rozwiązań SaaS zostanie zbudowana na jednej z wiodących infrastruktur chmurowych, takich jak Azure czy Amazon. Wielu wiodących dostawców posiada zaawansowane infrastruktury bezpieczeństwa. Są mocno zainwestowani we wspieranie potrzeb swoich klientów w zakresie zgodności.
Wysoka dostępność
Dobrą wiadomością jest to, że jest to odpowiedzialność sprzedawcy. Warto skontaktować się z dostawcą, aby dowiedzieć się, jakie przepisy wprowadził w zakresie przełączania awaryjnego i wysokiej dostępności. Aplikacje SaaS powinny być zaprojektowane tak, aby były bardzo odporne. Różne usługi składające się na aplikację SaaS są zazwyczaj zaprojektowane tak, aby były indywidualnie odporne. Można również przewidzieć przestoje w centrach danych, w przypadku których aplikacja przeszłaby awaryjnie z jednego centrum danych do drugiego w przypadku awarii centrum danych.
