Optymalizowanie wydajności na maszynach wirtualnych z systemem Linux z serii Lsv3, Lasv3 i Lsv2

  • Artykuł

Uwaga

W tym artykule odwołuje się do systemu CentOS — dystrybucji systemu Linux, która zbliża się do stanu zakończenia życia (EOL). Rozważ odpowiednie użycie i zaplanuj. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zakończenia życia systemu CentOS.

Dotyczy: ✔️ Maszyny wirtualne z systemem Linux Jednolite zestawy ✔️ skalowania

Maszyny wirtualne platformy Azure z serii Lsv3, Lasv3 i Lsv2 obsługują różne obciążenia, które wymagają wysokiej przepływności we/wy w magazynie lokalnym w wielu różnych aplikacjach i branżach. Seria L jest idealna dla baz danych Big Data, SQL, NoSQL, magazynowania danych i dużych transakcyjnych baz danych, w tym Cassandra, MongoDB, Cloudera i Redis.

Kilka kompilacji jest dostępnych w witrynie Azure Marketplace ze względu na pracę z partnerami w systemie Linux. Te kompilacje są zoptymalizowane pod kątem wydajności serii Lsv3, Lasv3 i Lsv2. Dostępne kompilacje obejmują następujące i nowsze wersje:

  • Ubuntu 16.04
  • RHEL 8.0 i klony, w tym CentOS, Rocky Linux i Alma Linux
  • Debian 9
  • SUSE Linux 15
  • Oracle Linux 8.0

Ten artykuł zawiera porady i sugestie, aby zapewnić, że obciążenia i aplikacje osiągną maksymalną wydajność zaprojektowaną na maszynach wirtualnych.

Architektura mikroukładu AMD EPYC™

Maszyny wirtualne z serii Lasv3 i Lsv2 korzystają z procesorów serwera AMD EPYC™ opartych na mikro architekturze Zen. Firma AMD opracowała sieć Szkieletową Infinity Fabric (IF) dla EPYC™ jako skalowalne połączenia międzyoperacyjne dla swojego modelu NUMA, który może być używany do komunikacji w trybie "die", "on-package" i "multi-package". W porównaniu z procesorami QPI (Quick-Path Interconnect) i UPI (Ultra-Path Interconnect) używanymi w nowoczesnych procesorach monolitycznych procesorów monolitycznych procesorów procesorów monolitycznych, architektura firmy AMD o małych kostkach NUMA może przynieść zarówno korzyści wydajności, jak i wyzwania. Rzeczywiste skutki ograniczeń przepustowości i opóźnień pamięci mogą się różnić w zależności od typu uruchomionych obciążeń.

Wskazówki w celu zmaksymalizowania wydajności

  • Jeśli przekazujesz niestandardowy system Linux GuestOS dla obciążenia, przyspieszona sieć jest domyślnie wyłączona. Jeśli zamierzasz włączyć przyspieszoną sieć, włącz ją w momencie tworzenia maszyny wirtualnej, aby uzyskać najlepszą wydajność.
  • Aby uzyskać maksymalną wydajność, uruchom wiele zadań z głęboką głębokością kolejki na urządzenie.
  • Unikaj mieszania poleceń administratora NVMe (na przykład zapytania NVMe SMART info itp.) za pomocą poleceń we/wy NVMe podczas aktywnych obciążeń. Urządzenia Lsv3, Lasv3 i Lsv2 NVMe są wspierane przez technologię NvMe Direct funkcji Hyper-V, która przełącza się w tryb "powolny", gdy wszystkie polecenia administratora NVMe oczekują. Użytkownicy Lsv3, Lasv3 i Lsv2 mogą zobaczyć dramatyczny spadek wydajności we/wy nvme, jeśli tak się stanie.
  • Użytkownicy Lsv2 nie zaleca się polegania na informacjach NUMA urządzenia (wszystkich 0) zgłoszonych z poziomu maszyny wirtualnej dla dysków danych w celu podjęcia decyzji o koligacji NUMA dla swoich aplikacji. Zalecanym sposobem na lepszą wydajność jest rozłożenie obciążeń między procesory CPU, jeśli jest to możliwe.
  • Maksymalna obsługiwana głębokość kolejki na parę kolejek we/wy dla urządzeń Lsv3, Lasv3 i Lsv2 VM NVMe wynosi 1024. Użytkownicy Lsv3, Lasv3 i Lsv2 zaleca się ograniczenie obciążeń porównawczych (syntetycznych) do głębokości kolejki 1024 lub niższej, aby uniknąć wyzwalania pełnych warunków kolejki, co może zmniejszyć wydajność.
  • Najlepszą wydajność uzyskuje się, gdy we/wy odbywa się bezpośrednio do każdego z nieprzetworzonych urządzeń NVMe bez partycjonowania, bez systemów plików, bez konfiguracji RAID itp. Przed rozpoczęciem sesji testowania upewnij się, że konfiguracja jest w znanym stanie świeżego/czystego, uruchamiając blkdiscard je na każdym urządzeniu NVMe. Aby uzyskać najbardziej spójną wydajność podczas testowania porównawczego, zaleca się wstępne przygotowanie urządzeń NVMe przed przetestowaniem przez wystawienie losowych zapisów do wszystkich urządzeń LBA dwukrotnie zgodnie z definicją w specyfikacji SNIA Solid State Storage Enterprise Performance Test Test.

Korzystanie z lokalnego magazynu NVMe

Magazyn lokalny na dysku NVMe o pojemności 1,92 TB na wszystkich maszynach wirtualnych Lsv3, Lasv3 i Lsv2 jest efemeryczny. Podczas pomyślnego standardowego ponownego rozruchu maszyny wirtualnej dane na lokalnym dysku NVMe są utrwalane. Dane nie są utrwalane na urządzeniu NVMe, jeśli maszyna wirtualna zostanie ponownie wdrożona, cofnięto przydział lub usunięto. Dane nie są utrwalane, jeśli inny problem powoduje, że maszyna wirtualna lub sprzęt, na którym jest uruchomiona, stanie się w złej kondycji. W przypadku scenariusza wszystkie dane na starym hoście są bezpiecznie usuwane.

Istnieją również przypadki, w których maszyna wirtualna musi zostać przeniesiona na inną maszynę hosta, na przykład podczas planowanej konserwacji. Planowane operacje konserwacji i niektóre awarie sprzętu można przewidzieć w przypadku zaplanowanych zdarzeń. Użyj zaplanowanych zdarzeń, aby zachować aktualną każdą przewidywaną konserwację i operacje odzyskiwania.

W przypadku, gdy zdarzenie planowanej konserwacji wymaga ponownego utworzenia maszyny wirtualnej na nowym hoście z pustymi dyskami lokalnymi, dane muszą zostać ponownie zsynchronizowane (ponownie ze wszystkimi danymi na starym hoście, które są bezpiecznie wymazane). Ten scenariusz występuje, ponieważ maszyny wirtualne lsv3, Lasv3 i Lsv2 nie obsługują obecnie migracji na żywo na lokalnym dysku NVMe.

Istnieją dwa tryby planowanej konserwacji.

Konserwacja sterowana przez klienta na standardowej maszynie wirtualnej

  • Maszyna wirtualna jest przenoszona do zaktualizowanego hosta w ciągu 30 dni.
  • Dane magazynu lokalnego Lsv3, Lasv3 i Lsv2 mogą zostać utracone, dlatego zalecane jest tworzenie kopii zapasowych danych przed zdarzeniem.

Automatyczna konserwacja

  • Występuje, jeśli klient nie wykonuje konserwacji kontrolowanej przez klienta lub z powodu procedur awaryjnych, takich jak zdarzenie zero-dniowe zabezpieczeń.
  • Ma na celu zachowanie danych klientów, ale istnieje niewielkie ryzyko zamrożenia lub ponownego uruchomienia maszyny wirtualnej.
  • Dane magazynu lokalnego Lsv3, Lasv3 i Lsv2 mogą zostać utracone, dlatego zalecane jest tworzenie kopii zapasowych danych przed zdarzeniem.

W przypadku wszelkich nadchodzących zdarzeń usługi użyj kontrolowanego procesu konserwacji, aby wybrać najbardziej wygodny czas aktualizacji. Przed zdarzeniem wykonaj kopię zapasową danych w usłudze Premium Storage. Po zakończeniu zdarzenia konserwacji możesz zwrócić dane do odświeżonego magazynu Lsv3, Lasv3 i Lsv2.

Scenariusze, które utrzymują dane na lokalnych dyskach NVMe, obejmują:

  • Maszyna wirtualna działa i jest w dobrej kondycji.
  • Maszyna wirtualna jest uruchamiana ponownie (przez Ciebie lub platformę Azure).
  • Maszyna wirtualna jest wstrzymana (zatrzymana bez cofnięcia przydziału).
  • Większość operacji obsługi planowanej konserwacji.

Scenariusze, które bezpiecznie usuwają dane w celu ochrony klienta, obejmują:

  • Maszyna wirtualna zostanie ponownie wdrożona, zatrzymana (cofnięto przydział) lub usunięta (przez Ciebie).
  • Maszyna wirtualna staje się w złej kondycji i musi zostać naprawiona w innym węźle z powodu problemu ze sprzętem.
  • Kilka operacji obsługi planowanej konserwacji, które wymagają przeniesienia maszyny wirtualnej do innego hosta na potrzeby obsługi.

Często zadawane pytania

Poniżej przedstawiono często zadawane pytania dotyczące tej serii.

Jak mogę rozpocząć wdrażanie maszyn wirtualnych serii L?

Podobnie jak każda inna maszyna wirtualna, użyj witryny Portal, interfejsu wiersza polecenia platformy Azure lub programu PowerShell, aby utworzyć maszynę wirtualną.

Czy awaria pojedynczego dysku NVMe powoduje niepowodzenie wszystkich maszyn wirtualnych na hoście?

Jeśli na węźle sprzętowym zostanie wykryta awaria dysku, sprzęt jest w stanie awarii. Gdy wystąpi ten problem, wszystkie maszyny wirtualne w węźle zostaną automatycznie cofnięte i przeniesione do węzła w dobrej kondycji. W przypadku maszyn wirtualnych z serii Lsv3, Lasv3 i Lsv2 ten problem oznacza, że dane klienta w węźle kończącym się niepowodzeniem również są bezpiecznie usuwane. Klient musi ponownie utworzyć dane w nowym węźle.

Czy muszę zmienić ustawienia blk_mq?

System RHEL/CentOS 7.x automatycznie używa blk-mq dla urządzeń NVMe. Nie są wymagane żadne zmiany konfiguracji ani ustawienia.

Następne kroki

Zobacz specyfikacje wszystkich maszyn wirtualnych zoptymalizowanych pod kątem wydajności magazynu na platformie Azure