Ten artykuł jest częścią serii, która opiera się na architekturze referencyjnej lokalnego punktu odniesienia platformy Azure azure. Aby skutecznie wdrożyć usługę Azure Local przy użyciu bez przełącznika magazynu z trzema węzłami projektu, ważne jest, aby zrozumieć architekturę punktu odniesienia. Ten proces obejmuje zapoznanie się z wyborami projektowymi klastra dla węzłów fizycznych, które zapewniają lokalne możliwości obliczeniowe, magazynowe i sieciowe. Ta wiedza ułatwia zidentyfikowanie niezbędnych zmian w przypadku pomyślnego wdrożenia. Wskazówki przedstawione w tym artykule dotyczą również bez przełącznika magazynu dwuwęzłowego wdrożenia i dokonuje niezbędnych korekt w przypadkach, gdy liczba węzłów fizycznych spada z trzech do dwóch.
Projekt sieci bez przełącznika magazynu eliminuje wymaganie, aby przełączniki sieciowe klasy magazynu łączyły porty karty sieciowej używane na potrzeby ruchu magazynu. Zamiast tego węzły są bezpośrednio połączone za pomocą ethernetowych. Ta konfiguracja jest często używana w scenariuszach sprzedaży detalicznej, produkcji lub biura zdalnego. Ta konfiguracja jest również odpowiednia dla mniejszych przypadków użycia brzegowych, które nie mają lub nie wymagają rozbudowanych przełączników sieciowych centrum danych na potrzeby ruchu replikacji magazynu.
Ta architektura referencyjna zawiera niezależne od obciążeń wskazówki i zalecenia dotyczące konfigurowania platformy Azure Local jako odpornej platformy infrastruktury do wdrażania obciążeń zwirtualizowanych i zarządzania nimi. Aby uzyskać więcej informacji na temat wzorców architektury obciążenia zoptymalizowanych pod kątem uruchamiania w usłudze Azure Local, zobacz zawartość znajdującą się w menu nawigacji obciążenia lokalne platformy Azure.
Ta architektura jest punktem wyjścia dla trzywęźle wystąpienia lokalnego platformy Azure, które korzysta z projektu sieci bez przełącznika magazynu. Aplikacje obciążeń wdrożone w wystąpieniu lokalnym platformy Azure powinny być dobrze zaprojektowane. Takie podejście obejmuje wdrażanie wielu wystąpień w celu zapewnienia wysokiej dostępności wszystkich krytycznych usług obciążeń oraz implementowanie odpowiednich mechanizmów kontroli ciągłości działania i odzyskiwania po awarii (BCDR), takich jak regularne kopie zapasowe i możliwości trybu failover odzyskiwania po awarii. Aby skoncentrować się na platformie infrastruktury HCI, te aspekty projektowania obciążenia są celowo wykluczone z tego artykułu. Aby uzyskać więcej informacji na temat wytycznych i zaleceń dotyczących pięciu filarów platformy Azure Well-Architected Framework, zobacz przewodnik Azure Local Well-Architected Framework.
Układ artykułu
Architektura | Decyzje projektowe | podejście Well-Architected Framework |
---|---|---|
▪ diagram architektury ▪ Potencjalne przypadki użycia ▪ Wdrażanie tego scenariusza |
▪ Wybór projektu klastra ▪ sieci |
▪ optymalizacja kosztów ▪ wydajność |
Napiwek
Architektura
Aby uzyskać więcej informacji na temat tych zasobów, zobacz Powiązane zasoby.
Potencjalne przypadki użycia
Użyj tego projektu i projektów opisanych w lokalnej architektury referencyjnej punktu odniesienia platformy Azure, aby spełnić następujące wymagania dotyczące przypadków użycia:
Wdrażanie zwirtualizowanych lub opartych na kontenerach obciążeń brzegowych o wysokiej dostępności i zarządzanie nimi, które są wdrażane w jednej lokalizacji, aby umożliwić działanie aplikacji i usług o krytycznym znaczeniu dla działania w sposób odporny, ekonomiczny i skalowalny.
Projekt sieci bez przełącznika magazynu eliminuje wymóg wdrożenia przełączników sieciowych klasy magazynu w celu połączenia portów karty sieciowej używanych do ruchu magazynu.
Można użyć projektu sieci bez przełącznika magazynu, aby zmniejszyć koszty związane z zakupem i konfiguracją przełączników sieciowych klasy magazynu dla ruchu magazynu, ale zwiększa liczbę portów kart sieciowych wymaganych w węzłach fizycznych.
Składniki architektury
Zasoby architektury pozostają w większości niezmienione z architektury referencyjnej punktu odniesienia. Aby uzyskać więcej informacji, zobacz zasoby platformy i platformy pomocnicze używane na potrzeby wdrożeń lokalnych platformy Azure.
Opcje projektowania klastra
Podczas określania opcji projektowania klastra zapoznaj się z architekturą referencyjną punktu odniesienia . Użyj tych szczegółowych informacji i narzędzia lokalnego rozmiaru platformy Azure, aby odpowiednio skalować wystąpienie lokalne platformy Azure zgodnie z wymaganiami dotyczącymi obciążenia.
W przypadku korzystania z projektu bez przełącznika magazynu należy pamiętać, że klaster z trzema węzłami jest maksymalnym obsługiwanym rozmiarem. To ograniczenie jest kluczowym czynnikiem do wyboru projektu klastra, ponieważ należy upewnić się, że wymagania dotyczące pojemności obciążenia nie przekraczają możliwości pojemności fizycznej specyfikacji klastra z trzema węzłami. Ponieważ nie można wykonać gestu dodawania węzła w celu rozszerzenia klastra bez przełącznika magazynu poza trzema węzłami, bardzo ważne, aby poznać wymagania dotyczące pojemności obciążenia wcześniej i zaplanować przyszły rozwój. Dzięki temu możesz mieć pewność, że obciążenie nie przekracza pojemności magazynu i mocy obliczeniowej w oczekiwanym okresie trwania sprzętu wystąpienia lokalnego platformy Azure.
Ostrożność
Maksymalny obsługiwany rozmiar klastra dla architektury sieci bez przełącznika magazynu to trzy węzły fizyczne. Pamiętaj, aby wziąć pod uwagę ten limit w fazie projektowania klastra, na przykład uwzględnić obecne i przyszłe wymagania dotyczące pojemności wzrostu obciążenia.
Projekt sieci
Projekt sieci odnosi się do ogólnego układu składników fizycznych i logicznych w sieci. W konfiguracji bez przełącznika magazynu z trzema węzłami dla usługi Azure Local trzy węzły fizyczne są połączone bezpośrednio bez użycia przełącznika zewnętrznego dla ruchu magazynu. Te bezpośrednie połączenia ethernetowe upraszczają projektowanie sieci, zmniejszając złożoność, ponieważ nie ma potrzeby definiowania ani stosowania konfiguracji jakości usługi i priorytetyzacji magazynu na przełącznikach. Technologie, które stanowią podstawę bezstratnej komunikacji RDMA, takie jak jawne powiadomienie o przeciążeniu (ECN), kontrola przepływu priorytetu (PFC) lub jakość usług (QoS), które są wymagane dla roCE v2 i iWARP, nie są potrzebne. Jednak ta konfiguracja obsługuje maksymalnie trzy węzły, co oznacza, że nie można skalować klastra, dodając więcej węzłów po wdrożeniu.
Nuta
Ta architektura bez przełącznika magazynu z trzema węzłami wymaga sześciu portów karty sieciowej, które zapewniają nadmiarowe łącza dla wszystkich intencji sieciowych. Należy to wziąć pod uwagę, jeśli planujesz użyć małej jednostki SKU form-factor lub jeśli w obudowie serwera jest ograniczona ilość miejsca fizycznego dla dodatkowych kart sieciowych. Aby uzyskać więcej informacji, zapoznaj się z preferowanym partnerem producenta sprzętu.
Topologia sieci fizycznej
Topologia sieci fizycznej przedstawia rzeczywiste połączenia fizyczne między węzłami i składnikami sieci. Połączenia między węzłami i składnikami sieciowymi dla bez przełącznika magazynu trzywęzłowego wdrożenia lokalnego platformy Azure to:
Trzy węzły (lub serwery):
Każdy węzeł jest serwerem fizycznym, który działa w systemie operacyjnym Azure Stack HCI.
Każdy węzeł wymaga łącznie sześciu portów karty sieciowej: cztery porty obsługujące funkcję RDMA dla magazynu i dwa porty do zarządzania i obliczeń.
Ruch magazynu:
Każdy z trzech węzłów jest połączony za pośrednictwem dwóch dedykowanych fizycznych portów karty sieciowej dla magazynu. Na poniższym diagramie przedstawiono ten proces.
Porty karty sieciowej magazynu łączą się bezpośrednio z każdym węzłem przy użyciu Ethernet w celu utworzenia architektury sieci pełnej siatki dla ruchu magazynu.
Ten projekt zapewnia nadmiarowość łączy, dedykowane małe opóźnienia, wysoką przepustowość i wysoką przepływność.
Węzły w klastrze HCI komunikują się bezpośrednio za pośrednictwem tych linków w celu obsługi ruchu replikacji magazynu, znanego również jako ruch wschodnio-zachodni.
Ta bezpośrednia komunikacja eliminuje konieczność korzystania z dodatkowych portów przełącznika sieciowego dla magazynu i eliminuje konieczność zastosowania konfiguracji QoS lub PFC dla ruchu SMB Direct lub RDMA na przełącznikach sieciowych.
Zapoznaj się z partnerem producenta sprzętu lub dostawcą karty sieciowej (NIC), aby uzyskać informacje o zalecanych sterownikach systemu operacyjnego, wersjach oprogramowania układowego lub ustawieniach oprogramowania układowego dla konfiguracji sieciowej bez przełącznika połączenia.
Dwa przełączniki typu Top-of-Rack (ToR):
Ta konfiguracja jest bez przełączników dla ruchu magazynu, ale nadal wymaga przełączników ToR dla łączności zewnętrznej. Ta łączność jest nazywana ruchem północno-południowym i obejmuje intencję zarządzania klastrem
oraz intencje obliczeniowe obciążenia.Pasma do przełączników z każdego węzła używają dwóch portów karty sieciowej. Ethernet łączą te porty, jeden z każdym przełącznikiem ToR, aby zapewnić nadmiarowość łącza.
Zalecamy użycie podwójnych przełączników ToR w celu zapewnienia nadmiarowości operacji obsługi i równoważenia obciążenia na potrzeby komunikacji zewnętrznej.
Łączność zewnętrzna:
Podwójne przełączniki toR łączą się z siecią zewnętrzną, taką jak wewnętrzna firmowa sieć LAN, i używają urządzenia sieciowego brzegowego, takiego jak zapora lub router, w celu zapewnienia dostępu do wymaganych adresów URL ruchu wychodzącego.
Dwa przełączniki toR obsługują ruch północno-południowy dla wystąpienia lokalnego platformy Azure, w tym ruch związany z intencjami zarządzania i obliczeń.
Topologia sieci logicznej
Topologia sieci logicznej zawiera omówienie sposobu przepływu danych sieciowych między urządzeniami, niezależnie od ich połączeń fizycznych. Poniższa lista zawiera podsumowanie konfiguracji logicznej dla wystąpienia lokalnego platformy Azure bez przełącznika magazynu z trzema węzłami:
Przełączniki Podwójne toR:
- Przed wdrożeniem klastra należy skonfigurować dwa przełączniki sieciowe toR z wymaganymi identyfikatorami sieci VLAN i ustawieniami maksymalnej jednostki transmisji (MTU) dla portów zarządzania i obliczeń. Aby uzyskać więcej informacji, zobacz wymagania dotyczące sieci fizycznej lub poproś partnera integratora sprzętu przełącznika lub integratora systemów (SI), aby uzyskać pomoc.
Usługa Azure Local stosuje automatyzację sieci i konfigurację sieci opartą intencji przy użyciu usługi Network ATC.
Usługa Network ATC została zaprojektowana w celu zapewnienia optymalnej konfiguracji sieci i przepływu ruchu przy użyciu ruchu sieciowego intencji. Usługa Network ATC definiuje, które fizyczne porty karty sieciowej są używane dla różnych intencji ruchu sieciowego (lub typów), takich jak dla klastra zarządzania, obciążenia obliczeniowychi intencji magazynu klastra.
Zasady oparte na intencjach upraszczają wymagania dotyczące konfiguracji sieci, automatyzując konfigurację sieci węzła na podstawie danych wejściowych parametrów określonych w ramach procesu wdrażania w chmurze lokalnej platformy Azure.
Komunikacja zewnętrzna:
Gdy węzły lub obciążenie muszą komunikować się zewnętrznie przez uzyskanie dostępu do firmowej sieci LAN, Internetu lub innej usługi, są one kierowane przy użyciu przełączników podwójnych tor. Ten proces został opisany w poprzedniej sekcji Topologia sieci fizycznej.
Gdy dwa przełączniki tor działają jako urządzenia warstwy 3, obsługują routing i zapewniają łączność poza klastrem z urządzeniem granicznym brzegowym, takim jak zapora lub router.
Intencja sieci zarządzania używa interfejsu wirtualnego Set (Converged Switch Embedded Teaming), który umożliwia zasobom płaszczyzny sterowania i adresowi IP zarządzania klastrem komunikację zewnętrzną.
W przypadku intencji sieci obliczeniowej można utworzyć co najmniej jedną sieć logiczną na platformie Azure z określonymi identyfikatorami sieci VLAN dla danego środowiska. Zasoby obciążenia, takie jak maszyny wirtualne, używają tych identyfikatorów w celu udzielenia dostępu do sieci fizycznej. Sieci logiczne używają dwóch fizycznych portów karty sieciowej, które są zbieżne przy użyciu zestawu dla intencji obliczeniowych i zarządzania.
Ruch magazynu:
Węzły komunikują się ze sobą bezpośrednio na potrzeby ruchu magazynu przy użyciu czterech bezpośrednich portów ethernet dla każdego węzła, które używają sześciu oddzielnych sieci bez routingu (lub warstwy 2) dla ruchu magazynu.
Nie bramy domyślnej skonfigurowane na czterech portach karty sieciowej intencji magazynu w systemie operacyjnym Azure Stack HCI.
Każdy węzeł może uzyskać dostęp do funkcji S2D klastra, takich jak zdalne dyski fizyczne, które są używane w puli magazynów, dyskach wirtualnych i woluminach. Dostęp do tych funkcji jest ułatwiany za pośrednictwem protokołu RDMA SMB Direct za pośrednictwem dwóch dedykowanych portów karty sieciowej magazynu dostępnych w każdym węźle. Funkcja SMB Multichannel jest używana do odporności.
Ta konfiguracja zapewnia wystarczającą szybkość transferu danych dla operacji związanych z magazynem, takich jak utrzymywanie spójnych kopii danych dla woluminów dublowanych.
Wymagania dotyczące adresów IP
Aby wdrożyć konfigurację bez przełącznika magazynu z trzema węzłami usługi Azure Local z dwoma linkami dla połączeń między magazynami, platforma infrastruktury klastra wymaga przydzielenia co najmniej 20 x adresów IP. Jeśli używasz urządzenia maszyny wirtualnej dostarczonego przez partnera producenta sprzętu, lub jeśli używasz mikrosegmentacji lub sieci zdefiniowanej przez oprogramowanie (SDN). Aby uzyskać więcej informacji, zobacz Zapoznaj się z wymaganiami dotyczącymi adresów IP wzorca referencyjnego magazynu z trzema węzłami dla usługi Azure Local.
Podczas projektowania i planowania wymagań dotyczących adresów IP dla usługi Azure Local pamiętaj, aby uwzględnić dodatkowe adresy IP lub zakresy sieci wymagane dla obciążenia poza wymaganiami dotyczącymi lokalnego wystąpienia i składników infrastruktury platformy Azure. Jeśli planujesz używać usług Azure Kubernetes Services (AKS) w usłudze Azure Local, zobacz AKS włączone przez wymagania dotyczące sieci usługi Azure Arc.
Zagadnienia dotyczące
Te zagadnienia obejmują implementację filarów platformy Azure Well-Architected Framework, która jest zestawem wytycznych, które mogą służyć do poprawy jakości obciążenia. Aby uzyskać więcej informacji, zobacz Microsoft Azure Well-Architected Framework.
Ważny
Zapoznaj się z zagadnieniami dotyczącymi platformy Well-Architected Opisanymi w lokalnej architektury referencyjnej punktu odniesienia platformy Azure.
Optymalizacja kosztów
Optymalizacja kosztów dotyczy sposobów zmniejszenia niepotrzebnych wydatków i poprawy wydajności operacyjnej. Aby uzyskać więcej informacji, zobacz Omówienie filaru optymalizacji kosztów.
Zagadnienia dotyczące optymalizacji kosztów obejmują:
- Połączenia między klastrami bez przełączników a połączenia między klastrami opartymi na przełącznikach. Topologia połączenia bez przełącznika składa się z połączeń między dwoma portami lub nadmiarowych, portów kart sieciowych obsługujących funkcję RDMA w każdym węźle w celu utworzenia pełnej siatki. Każdy węzeł ma dwa bezpośrednie połączenia z każdym innym węzłem. Chociaż ta implementacja jest prosta, jest obsługiwana tylko w klastrach z dwoma węzłami lub trzema węzłami. Wystąpienie lokalne platformy Azure z co najmniej czterema węzłami wymaga przełączenia magazynu architektury sieci. Za pomocą tej architektury można dodać więcej węzłów po wdrożeniu, w przeciwieństwie do projektu bez przełącznika magazynu, który nie obsługuje operacji dodawania węzłów.
Wydajność
Wydajność to możliwość skalowania obciążenia w celu spełnienia wymagań, które są na nim nakładane przez użytkowników w wydajny sposób. Aby uzyskać więcej informacji, zobacz
Zagadnienia dotyczące wydajności obejmują:
- Nie można zwiększyć skali (ani wykonać operacji dodawania węzła) istniejącego klastra hcI bez przełącznika magazynu z trzema węzłami bez konieczności ponownego wdrażania klastra i dodawania dodatkowych funkcji sieciowych, takich jak przełączniki sieciowe, porty i dla ruchu magazynu oraz inne wymagane węzły. Trzy węzły są maksymalnym obsługiwanym rozmiarem klastra dla projektu sieci bez przełącznika magazynu. Należy uwzględnić to ograniczenie w fazie projektowania klastra, aby zapewnić, że sprzęt może obsługiwać przyszły wzrost pojemności obciążenia.
Wdróż ten scenariusz
Aby uzyskać więcej informacji na temat projektowania, pozyskiwania i wdrażania rozwiązania lokalnego platformy Azure, zobacz sekcję Wdrażanie tego scenariusza w architekturze referencyjnej lokalnego punktu odniesienia platformy Azure .
Użyj następującego szablonu automatyzacji wdrażania jako przykładu wdrażania usługi Azure Local przy użyciu architektury bez przełącznika magazynu z trzema węzłami.
Napiwek
Powiązane zasoby
- projektowanie architektury hybrydowej
- opcje hybrydowe platformy Azure
- azure Automation w środowisku hybrydowym
- Azure Automation State Configuration
- Optymalizowanie administrowania wystąpieniami programu SQL Server w środowiskach lokalnych i wielochmurowych przy użyciu usługi Azure Arc
Następne kroki
Dokumentacja produktu:
- systemu operacyjnego Azure Stack HCI w wersji 23H2
- AKS w lokalnej platformy Azure
- Azure Virtual Desktop for Azure Local
- Co to jest lokalne monitorowanie platformy Azure?
- Ochrona obciążeń maszyn wirtualnych za pomocą usługi Site Recovery w lokalnej platformy Azure
- Omówienie usługi Azure Monitor
- Śledzenie zmian i spis — omówienie
- Omówienie usługi Azure Update Manager
- Co to są usługi danych z obsługą usługi Azure Arc?
- Co to są serwery z obsługą usługi Azure Arc?
- Co to jest usługa Azure Backup?
- Wprowadzenie do docelowego środowiska obliczeniowego Kubernetes w usłudze Azure Machine Learning
Dokumentacja produktu dla określonych usług platformy Azure:
- lokalnej platformy Azure
- azure arc
- usługi Azure Key Vault
- usługi Azure Blob Storage
- Monitor
- azure policy
- usługi Azure Container Registry
- Microsoft Defender for Cloud
- Azure Site Recovery
- kopii zapasowej
Moduły microsoft Learn:
- Konfigurowanie monitora
- Projektowanie rozwiązania do odzyskiwania lokacji w usłudze Azure
- Wprowadzenie do serwerów z obsługą usługi Azure Arc
- Wprowadzenie do usług danych z obsługą usługi Azure Arc
- Wprowadzenie do usługi AKS
- Skalowanie wdrożenia modelu za pomocą usługi Azure Machine Learning w dowolnym miejscu — blog społeczności technicznej
- Realizowanie uczenia maszynowego w dowolnym miejscu za pomocą usługi AKS i uczenia maszynowego z obsługą usługi Arc — blog społeczności technicznej
- uczenie maszynowe w hybrydowej usłudze AKS i rozwiązaniu Stack HCI przy użyciu uczenia maszynowego z obsługą usługi Azure Arc — blog społeczności technicznej
- Aktualizowanie maszyn wirtualnych
- Ochrona ustawień maszyny wirtualnej za pomocą usługi Azure Automation State Configuration
- Ochrona maszyn wirtualnych przy użyciu kopii zapasowych