Uruchamianie oprogramowania Apache Cassandra na maszynach wirtualnych platformy Azure
W tym artykule opisano zagadnienia dotyczące wydajności uruchamiania oprogramowania 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.
Wystąpienie zarządzane platformy Azure dla platformy Apache Cassandra
Jeśli szukasz bardziej zautomatyzowanej usługi do uruchamiania platformy 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ść 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. Poniższe zalecenia zostały przyjęte podczas opracowywania tej usługi.
Rozmiary i typy dysków maszyn wirtualnych platformy Azure
Obciążenia Cassandra na platformie Azure często używają Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 lub maszyn wirtualnych 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 zoptymalizowane pod kątem magazynu lokalnego , takie jak Standard_L16s_v3.
W przypadku 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 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 pasków z kilku dysków o rozmiarze 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 w porównaniu z 7,5 K dla jednego 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ą przepływność/liczbę operacji we/wy na sekundę 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 można łatwo odtworzyć dane 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 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 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 rozwiązania 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 za pomocą przyspieszonej 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, a nie 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 niebuforowanym 768 MB/s).
Buforowanie w trybie 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 o gęstości danych 1–2 TB.
W przypadku włączenia buforowania readOnly nie ma znaczącej kary za wydajność, dlatego tryb buforowania buforowanego jest zalecany dla wszystkich, ale dla najbardziej dużych obciążeń 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 Azure Marketplace domyślne ustawienie odczytu urządzenia blokowego wynosi 4096 KB. Operacje we/wy odczytu Cassandra są zwykle losowe i stosunkowo małe. W związku z tym duże obciążenie odczytu traci przepływność przez odczytywanie części plików, które nie są potrzebne.
Aby zminimalizować niepotrzebne spojrzenie, ustaw ustawienie odczytu urządzenia bloku systemu Linux na 8 KB. (Zobacz Zalecane ustawienia produkcyjne w dokumentacji narzędzia DataStax).
Skonfiguruj 8 KB odczytu do przodu dla wszystkich urządzeń blokowych w zestawie pasków i na samym urządzeniu tablicy (na przykład /dev/md0).
Aby uzyskać więcej informacji, zobacz Porównanie wpływu ustawień odczytu na dysk (GitHub).
Rozmiar fragmentu tablicy dyskowej mdadm
W przypadku uruchamiania rozwiązania Cassandra na platformie Azure typowe jest utworzenie zestawu 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ń SQL Server OLTP 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 jest mały, nieco zauważalny, zaleta 128k rozmiaru fragmentu. W związku z tym zalecamy wykonanie następujących czynności:
Jeśli używasz już rozmiaru fragmentu 64 K lub 256 K, nie ma sensu ponownie skompilować tablicy dyskowej w celu użycia rozmiaru 128 K.
W przypadku nowej konfiguracji warto używać od początku 128 K.
Aby uzyskać więcej informacji, zobacz Mierzenie wpływu rozmiarów fragmentów mdadm na wydajność cassandra (GitHub).
Zatwierdź system plików dziennika
Zapisy cassandra działają najlepiej, gdy dzienniki zatwierdzeń znajdują się na dyskach z dużą przepływnością i małym opóźnieniem. W konfiguracji domyślnej 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 zatwierdzania 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ść, przechowuj 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 kompresowane i nieskompresowane ext4 w naszych testach.
Aby uzyskać więcej informacji, zobacz Obserwacje systemów plików ext4 i xfs oraz skompresowane dzienniki zatwierdzeń (GitHub).
Mierzenie wydajności maszyny wirtualnej według planu bazowego
Po wdrożeniu maszyn wirtualnych dla pierścienia Cassandra uruchom kilka testów syntetycznych 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, gdy uruchamiasz rzeczywiste obciążenie, znajomość punktu odniesienia wydajności ułatwia badanie potencjalnych wąskich gardeł. Na przykład znajomość wydajności punktu odniesienia dla 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 Sprawdzanie poprawności wydajności 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 niższych 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 używania 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 będzie mieć 5, 10, 15 lub 20 węzłów. W przypadku korzystania z rf większego niż 1 i poziomu spójności LOCAL_QUORUM normalne jest, aby wydajność odczytu i zapisu była niższa niż to samo obciążenie uruchomione 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 stron 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ści odczytu względem tych samych danych drugi i kolejny odczyt będzie wyglądać znacznie szybciej niż oryginalny odczyt, który potrzebny do uzyskania dostępu do danych na dysku danych zdalnych 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 w buforowaniu stron systemu Linux (GitHub).
Replikacja w wielu centrach danych
Rozwiązanie Cassandra natywnie obsługuje koncepcję wielu centrów danych, co ułatwia konfigurowanie jednego pierścienia Cassandra w wielu regionach świadczenia usługi 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 punktu odniesienia między regionami. 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 spójności zapisu LOCAL_QUORUM lub znacznie zmniejszyła wydajność operacji zapisu podczas korzystania z EACH_QUORUM.
Po uruchomieniu platformy Apache Cassandra na dużą skalę, a w szczególności w środowisku z wieloma kontrolerami domeny naprawa węzłów 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 naraz, 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 ma zastosowanie 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 usługę Cassandra jest ograniczane do stosunkowo niskiej maksymalnej przepływności i trzygodzinnego okresu istnienia wskazówek. W przypadku obciążeń z dużymi zapisami zalecamy zwiększenie sugerowanego limitu 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 Microsoft. Pierwotnie został napisany przez następujących współautorów.
Główny autor:
- Arsen Władimirskiy | Główny inżynier klienta
Inny współautor:
- Theo van Kraay | Starszy menedżer programu
Aby wyświetlić niepubliowe profile usługi 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ń cassandra, a nie specyficznych dla platformy Azure, zobacz: