Uruchamianie oprogramowania Apache Cassandra na maszynach wirtualnych platformy Azure
Uwaga
W tym artykule odwołuje się centOS , dystrybucja systemu Linux, która jest end of life (EOL). Rozważ odpowiednie użycie i zaplanuj. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zakończenia życia systemu CentOS.
W tym artykule opisano zagadnienia dotyczące wydajności uruchamiania rozwiązania Apache Cassandra na maszynach wirtualnych platformy Azure.
Te zalecenia są oparte na wynikach testów wydajnościowych, które można znaleźć w witrynie GitHub. Należy użyć tych zaleceń jako punktu odniesienia, a następnie przetestować własne obciążenie.
Azure Managed Instance for Apache Cassandra
Jeśli szukasz bardziej zautomatyzowanej usługi do uruchamiania usługi Apache Cassandra na maszynach wirtualnych platformy Azure, rozważ użycie wystąpienia zarządzanego platformy Azure dla usługi Apache Cassandra. Ta usługa automatyzuje wdrażanie, zarządzanie (poprawianie i kondycję węzła) oraz skalowanie węzłów w klastrze Apache Cassandra. Zapewnia również możliwość użycia klastrów hybrydowych, dzięki czemu centra danych Apache Cassandra wdrożone na platformie Azure mogą dołączyć do istniejącego pierścienia Cassandra hostowanego lokalnie lub innej firmy. Usługa jest wdrażana przy użyciu usługi Azure Virtual Machine Scale Sets. Podczas opracowywania tej usługi przyjęto następujące zalecenia.
Rozmiary i typy dysków maszyn wirtualnych platformy Azure
Obciążenia cassandra na platformie Azure często używają maszyn wirtualnych Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 lub Standard_E16s_v5 . Obciążenia cassandra korzystają z większej ilości pamięci na maszynie wirtualnej, dlatego rozważ zoptymalizowane pod kątem pamięci rozmiary maszyn wirtualnych, takie jak Standard_DS14_v2 lub Standard_E16s_v5 lub rozmiary zoptymalizowane pod kątem magazynu lokalnego, takie jak Standard_L16s_v3.
W celu zapewnienia trwałości dzienniki danych i zatwierdzeń są często przechowywane w zestawie od dwóch do czterech dysków zarządzanych w warstwie Premium o pojemności 1 TB (P30).
Węzły bazy danych Cassandra nie powinny być zbyt gęste. Zalecamy posiadanie co najwyżej 1–2 TB danych na maszynę wirtualną i wystarczającą ilość wolnego miejsca na kompaktowanie. Aby uzyskać największą możliwą łączną przepływność i liczbę operacji we/wy na sekundę przy użyciu dysków zarządzanych w warstwie Premium, zalecamy utworzenie zestawu z kilku dysków o pojemności 1 TB zamiast jednego dysku o pojemności 2 TB lub 4 TB. Na przykład na maszynie wirtualnej DS14_v2 cztery dyski o rozmiarze 1 TB mają maksymalną liczbę operacji we/wy na sekundę wynoszącą 4 × 5000 = 20 K, a 7,5 K dla pojedynczego dysku o pojemności 4 TB.
Oceń dyski Azure Ultra Disks dla obciążeń Cassandra, które wymagają mniejszej pojemności dysku. Mogą one zapewnić większą liczbę operacji we/wy na sekundę/przepływność i mniejsze opóźnienia w rozmiarach maszyn wirtualnych, takich jak Standard_E16s_v5 i Standard_D16s_v5.
W przypadku obciążeń Cassandra, które nie wymagają trwałego magazynu — czyli tam, gdzie dane można łatwo odtworzyć z innego nośnika magazynu — rozważ użycie maszyn wirtualnych Standard_L16s_v3 lub Standard_L16s_v2 . Te rozmiary maszyn wirtualnych mają duże i szybkie lokalne tymczasowe dyski NVM Express (NVMe).
Aby uzyskać więcej informacji, zobacz Porównanie wydajności dysków lokalnych/efemerycznych platformy Azure i dołączonych /trwałych (GitHub).
Accelerated Networking
Węzły cassandra intensywnie wykorzystują sieć do wysyłania i odbierania danych z maszyny wirtualnej klienta oraz do komunikacji między węzłami na potrzeby replikacji. Aby uzyskać optymalną wydajność, maszyny wirtualne Cassandra korzystają z sieci o wysokiej przepływności i małych opóźnieniach.
Zalecamy włączenie przyspieszonej sieci na karcie sieciowej węzła Cassandra i na maszynach wirtualnych z uruchomionymi aplikacjami klienckimi, które uzyskują dostęp do bazy danych Cassandra.
Przyspieszona sieć wymaga nowoczesnej dystrybucji systemu Linux z najnowszymi sterownikami, takimi jak Cent OS 7.5+ lub Ubuntu 16.x/18.x. Aby uzyskać więcej informacji, zobacz Tworzenie maszyny wirtualnej z systemem Linux z przyspieszoną siecią.
Buforowanie dysku danych maszyny wirtualnej platformy Azure
Obciążenia odczytu cassandra działają najlepiej, gdy opóźnienie dysku z dostępem losowym jest niskie. Zalecamy używanie dysków zarządzanych platformy Azure z włączonym buforowaniem ReadOnly . Buforowanie readOnly zapewnia mniejsze średnie opóźnienie, ponieważ dane są odczytywane z pamięci podręcznej na hoście zamiast przechodzenia do magazynu zaplecza.
Obciążenia odczytu i odczytu losowego, takie jak Cassandra, korzystają z mniejszego opóźnienia odczytu, mimo że tryb buforowany ma mniejsze limity przepływności niż tryb bez buforowania. (Na przykład: DS14_v2 maszyny wirtualne mają maksymalną buforowaną przepływność wynoszącą 512 MB/s w porównaniu z niebuforowaną wartością 768 MB/s).
Buforowanie readOnly jest szczególnie przydatne w przypadku szeregów czasowych Cassandra i innych obciążeń, w których roboczy zestaw danych mieści się w pamięci podręcznej hosta, a dane nie są stale zastępowane. Na przykład DS14_v2 zapewnia rozmiar pamięci podręcznej 512 GB, który może przechowywać do 50% danych z węzła Cassandra z gęstością danych 1–2 TB.
W przypadku włączenia buforowania ReadOnly nie ma znaczącej kary za wydajność, dlatego tryb buforowany jest zalecany dla wszystkich obciążeń, ale dla większości obciążeń z dużym obciążeniem zapisu.
Aby uzyskać więcej informacji, zobacz Porównanie konfiguracji buforowania dysków danych maszyny wirtualnej platformy Azure (GitHub).
Odczyt w systemie Linux
W większości dystrybucji systemu Linux w witrynie Azure Marketplace domyślne ustawienie blokuj odczyt urządzenia to 4096 KB. Operacje we/wy odczytu bazy danych Cassandra są zwykle losowe i stosunkowo małe. W związku z tym duże obciążenie odczytu zmarnuje przepływność przez odczytywanie części plików, które nie są potrzebne.
Aby zminimalizować niepotrzebne spojrzenie, ustaw ustawienie odczytu z wyprzedzeniem urządzenia bloku systemu Linux na 8 KB. (Zobacz Zalecane ustawienia produkcyjne w dokumentacji usługi DataStax).
Skonfiguruj 8 KB odczytu przed wszystkimi urządzeniami blokowymi w zestawie paska i na samym urządzeniu tablicowym (na przykład /dev/md0).
Aby uzyskać więcej informacji, zobacz Porównanie wpływu ustawień odczytu dysku (GitHub).
Rozmiar fragmentu tablicy dysków mdadm
Podczas uruchamiania bazy danych Cassandra na platformie Azure często tworzy się zestaw pasków mdadm (czyli RAID 0) wielu dysków danych w celu zwiększenia ogólnej przepływności dysku i liczby operacji we/wy na sekundę bliżej limitów maszyn wirtualnych. Optymalny rozmiar paska dysku jest ustawieniem specyficznym dla aplikacji. Na przykład w przypadku obciążeń OLTP programu SQL Server zalecenie to 64 KB. W przypadku obciążeń magazynowania danych zalecenie to 256 KB.
Nasze testy nie wykazały znaczącej różnicy między rozmiarami fragmentów 64k, 128k i 256k dla obciążeń odczytu cassandra. Wydaje się, że istnieje niewielka, nieco zauważalna, zaleta 128k rozmiaru fragmentu. W związku z tym zalecamy wykonanie następujących czynności:
Jeśli używasz już rozmiaru fragmentu o rozmiarze 64 K lub 256 K, nie ma sensu ponownego kompilowania macierzy dyskowej w celu użycia rozmiaru 128 K.
W przypadku nowej konfiguracji warto używać 128 K od początku.
Aby uzyskać więcej informacji, zobacz Mierzenie wpływu rozmiarów fragmentów mdadm na wydajność bazy danych Cassandra (GitHub).
Zatwierdź system plików dziennika
Zapisy w systemie Cassandra działają najlepiej, gdy dzienniki zatwierdzeń znajdują się na dyskach z wysoką przepływnością i małymi opóźnieniami. W domyślnej konfiguracji system Cassandra 3.x opróżnia dane z pamięci do pliku dziennika zatwierdzeń co około 10 sekund i nie dotyka dysku dla każdego zapisu. W tej konfiguracji wydajność zapisu jest niemal identyczna, czy dziennik zatwierdzeń znajduje się na dyskach dołączonych w warstwie Premium, a na dyskach lokalnych/efemerycznych.
Dzienniki zatwierdzeń muszą być trwałe, aby ponownie uruchomiony węzeł mógł odtworzyć wszystkie dane, które nie zostały jeszcze w plikach danych z opróżnionych dzienników zatwierdzeń. Aby zapewnić lepszą trwałość, zapisz dzienniki zatwierdzeń na dyskach zarządzanych w warstwie Premium, a nie w magazynie lokalnym, co może zostać utracone, jeśli maszyna wirtualna zostanie zmigrowana do innego hosta.
Na podstawie naszych testów system Cassandra w systemie CentOS 7.x może mieć niższą wydajność zapisu, gdy dzienniki zatwierdzeń znajdują się w systemie plików xfs i ext4. Włączenie kompresji dziennika zatwierdzania zapewnia wydajność xfs zgodnie z ext4. Skompresowane pliki xfs są wykonywane, a także skompresowane i nieskompresowane ext4 w naszych testach.
Aby uzyskać więcej informacji, zobacz Obserwacje systemów plików ext4 i xfs oraz skompresowanych dzienników zatwierdzeń (GitHub).
Mierzenie wydajności podstawowej maszyny wirtualnej
Po wdrożeniu maszyn wirtualnych dla pierścienia Cassandra uruchom kilka syntetycznych testów w celu ustalenia wydajności sieci bazowej i dysku. Użyj tych testów, aby potwierdzić, że wydajność jest zgodna z oczekiwaniami na podstawie rozmiaru maszyny wirtualnej.
Później po uruchomieniu rzeczywistego obciążenia znajomość punktu odniesienia wydajności ułatwia badanie potencjalnych wąskich gardeł. Na przykład znajomość podstawowej wydajności ruchu wychodzącego sieci na maszynie wirtualnej może pomóc wykluczyć sieć jako wąskie gardło.
Aby uzyskać więcej informacji na temat uruchamiania testów wydajnościowych, zobacz Weryfikowanie wydajności podstawowej maszyny wirtualnej platformy Azure (GitHub).
Rozmiar dokumentu
Wydajność odczytu i zapisu w systemie Cassandra zależy od rozmiaru dokumentu. Podczas odczytywania lub zapisywania większych dokumentów można oczekiwać większego opóźnienia i mniejszych operacji na sekundę.
Aby uzyskać więcej informacji, zobacz Porównanie względnej wydajności różnych rozmiarów dokumentów Cassandra (GitHub).
Współczynnik replikacji
Większość obciążeń Cassandra używa współczynnika replikacji (RF) 3 w przypadku korzystania z dołączonych dysków w warstwie Premium, a nawet 5 w przypadku korzystania z tymczasowych/efemerycznych dysków lokalnych. Liczba węzłów w pierścieniu Cassandra powinna być wielokrotną liczbą współczynnika replikacji. Na przykład RF 3 oznacza pierścień 3, 6, 9 lub 12 węzłów, podczas gdy RF 5 miałby 5, 10, 15 lub 20 węzłów. W przypadku korzystania z RF większego niż 1 i poziomu spójności LOCAL_QUORUM wydajność odczytu i zapisu jest niższa niż to samo obciążenie z RF 1.
Aby uzyskać więcej informacji, zobacz Porównanie względnej wydajności różnych czynników replikacji (GitHub).
Buforowanie stron systemu Linux
Gdy kod Java cassandra odczytuje pliki danych, używa zwykłych operacji we/wy plików i korzysta z buforowania strony systemu Linux. Po jednorazowym odczytaniu części pliku zawartość odczytu jest przechowywana w pamięci podręcznej strony systemu operacyjnego. Dostęp do odczytu do tych samych danych jest znacznie szybszy.
Z tego powodu podczas wykonywania testów wydajnościowych odczytu względem tych samych danych drugi i kolejne operacje odczytu będą wyglądać znacznie szybciej niż oryginalny odczyt, co wymaga dostępu do danych na zdalnym dysku danych lub z pamięci podręcznej hosta po włączeniu funkcji ReadOnly. Aby uzyskać podobne pomiary wydajności w kolejnych uruchomieniach, wyczyść pamięć podręczną strony systemu Linux i uruchom ponownie usługę Cassandra, aby wyczyścić pamięć wewnętrzną. Po włączeniu buforowania ReadOnly dane mogą znajdować się w pamięci podręcznej hosta, a kolejne operacje odczytu będą szybsze nawet po wyczyszczeniu pamięci podręcznej strony systemu operacyjnego i ponownym uruchomieniu usługi Cassandra.
Aby uzyskać więcej informacji, zobacz Obserwacje dotyczące użycia bazy danych Cassandra buforowania strony systemu Linux (GitHub).
Replikacja z wieloma centrami danych
Rozwiązanie Cassandra natywnie obsługuje koncepcję wielu centrów danych, dzięki czemu można łatwo skonfigurować jeden pierścień Cassandra w wielu regionach platformy Azure lub w różnych strefach dostępności w jednym regionie.
W przypadku wdrożenia w wielu regionach użyj globalnej komunikacji równorzędnej sieci wirtualnych platformy Azure, aby połączyć sieci wirtualne w różnych regionach. Gdy maszyny wirtualne są wdrażane w tym samym regionie, ale w oddzielnych strefach dostępności, maszyny wirtualne mogą znajdować się w tej samej sieci wirtualnej.
Ważne jest, aby zmierzyć opóźnienie między regionami w punkcie bazowym. Opóźnienie sieci między regionami może być 10–100 razy większe niż opóźnienie w regionie. Spodziewaj się opóźnienia między danymi wyświetlanymi w drugim regionie podczas korzystania z LOCAL_QUORUM spójności zapisu lub znacznie zmniejszyła wydajność operacji zapisu podczas korzystania z EACH_QUORUM.
W przypadku uruchamiania systemu Apache Cassandra na dużą skalę, a w szczególności w środowisku z wieloma kontrolerami domeny naprawa węzła staje się trudna. Narzędzia takie jak Reaper mogą pomóc koordynować naprawy na dużą skalę (na przykład we wszystkich węzłach w centrum danych, jednym centrum danych w danym momencie, aby ograniczyć obciążenie całego klastra). Jednak naprawa węzłów dla dużych klastrów nie jest jeszcze w pełni rozwiązanym problemem i jest stosowana we wszystkich środowiskach, zarówno w środowisku lokalnym, jak i w chmurze.
Gdy węzły są dodawane do regionu pomocniczego, wydajność nie jest skalowana liniowo, ponieważ niektóre zasoby przepustowości i procesora CPU/dysku są wydawane na odbieranie i wysyłanie ruchu replikacji między regionami.
Aby uzyskać więcej informacji, zobacz Mierzenie wpływu replikacji obejmującej wiele regionów dc (GitHub).
Konfiguracja przekazywania wskazówek
W wieloregionowym pierścieniu Cassandra obciążenia zapisu z poziomem spójności LOCAL_QUORUM mogą utracić dane w regionie pomocniczym. Domyślnie przekazywanie sugerowane przez system Cassandra jest ograniczane do stosunkowo niskiej maksymalnej przepływności i trzygodzinnego okresu istnienia wskazówek. W przypadku obciążeń z dużymi operacjami zapisu zalecamy zwiększenie sugerowanego ograniczenia przepustowości przekazywania i czasu okna wskazówek, aby upewnić się, że wskazówki nie zostaną porzucone przed ich replikacją.
Aby uzyskać więcej informacji, zobacz Obserwacje dotyczące sugerowanej przekazywania w replikacji między regionami (GitHub).
Współautorzy
Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- Arsen Vladimirskiy | Główny inżynier klienta
Inny współautor:
- Theo van Kraay | Starszy menedżer programu
Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.
Następne kroki
Aby uzyskać więcej informacji na temat tych wyników wydajności, zobacz Cassandra on Azure VMs Performance Experiments (Eksperymenty wydajności maszyn wirtualnych platformy Azure).
Aby uzyskać informacje na temat ogólnych ustawień bazy danych Cassandra, a nie specyficznych dla platformy Azure, zobacz: