Uaktualnienia środowiska uruchomieniowego platformy Azure Operator Nexus

Uaktualnienie środowiska uruchomieniowego platformy Nexus jest destrukcyjnym uaktualnieniem zarządzanym przez klientów w celu zaktualizowania bazowego oprogramowania na serwerach w wystąpieniu Operatora Nexus. Zakłócenia występują na serwerach komputerowych w stojaku, który jest uaktualniany. Uaktualnienia serwera zarządzania są uznawane za niedestrukcyjne.

Zakres wydań środowiska uruchomieniowego

Uaktualnienie środowiska uruchomieniowego jest przeznaczone do aktualizowania podstawowych składników platformy dla każdego serwera w wystąpieniu. Niektóre przykłady składników zaktualizowanych podczas uaktualniania środowiska uruchomieniowego to system operacyjny , klaster kubernetes w chmurze, oprogramowanie układowe obliczeniowe, klaster etcd i CNI (interfejs sieciowy kontenera). Każdy serwer jest odtwarzany ponownie, aby załadować wybrany obraz wersji środowiska uruchomieniowego.

Częstotliwość wydawania

Wersje główne/drobne

Pomniejsze wydania środowiska uruchomieniowego są produkowane dla infrastruktury obliczeniowej trzy razy w roku w lutym, czerwcu i październiku. Te wersje są obsługiwane przez około rok po wydaniu, a klienci nie mogą pominąć wersji pomocniczych.

Aktualizacje poprawek

Wersja środowiska uruchomieniowego łatek jest generowana co miesiąc między pomniejszymi wersjami. Te wersje są opcjonalne, chyba że firma Microsoft tego wymaga dla konkretnych funkcji lub kwestii dotyczących zabezpieczeń.

Omówienie przepływu pracy

Uruchamianie uaktualnienia środowiska uruchomieniowego jest definiowane w obszarze Uaktualnianie środowiska uruchomieniowego klastra za pośrednictwem interfejsu wiersza polecenia platformy Azure.

Uaktualnienie środowiska uruchomieniowego rozpoczyna się od uaktualnienia trzech serwerów zarządzania wyznaczonych jako węzły płaszczyzny sterowania. Zapasowy serwer płaszczyzny sterowania jest pierwszym serwerem do uaktualnienia. Ostatni serwer płaszczyzny sterowania dezaktywuje się i przechodzi na Available stan. Te serwery są aktualizowane szeregowo, a następny jest aktualizowany dopiero po zakończeniu poprzedniego. Pozostałe serwery zarządzania są podzielone na dwie grupy. Uaktualnienie środowiska uruchomieniowego będzie teraz korzystać z dwóch grup zarządzania zamiast jednej grupy. Każda grupa jest aktualizowana w dwóch etapach i sekwencyjnie z progiem sukcesu wynoszącym 50% w każdej grupie. Wprowadzenie tej funkcji umożliwia korzystanie ze składników działających na serwerach zarządzania w celu zapewnienia niezawodności podczas aktualizacji środowiska wykonawczego przez zastosowanie reguł koligacji. W tej wersji każdy CSN będzie korzystać z tej funkcji, umieszczając jedno wystąpienie w każdej z grup zarządzania. Brak interakcji z tą funkcją przez klienta. W węzłach zarządzania mogą być widoczne dodatkowe etykiety umożliwiające zidentyfikowanie grup.

Po uaktualnieniu wszystkich serwerów zarządzania uaktualnienie przechodzi do serwerów obliczeniowych. Każdy stojak jest uaktualniany w kolejności alfanumerycznej, a istnieją różne konfiguracje, które klienci mogą wykorzystać do określenia, w jaki sposób komputery są uaktualniane, aby jak najlepiej zminimalizować zakłócenia. W miarę postępu każdej szafy są wykonywane różne testy integralności systemu w celu zapewnienia pomyślnej aktualizacji wydania i wystarczająca liczba serwerów w szafie powraca do stanu operacyjnego. Po zakończeniu stojaka zdefiniowany przez klienta czas oczekiwania zaczyna zapewniać dodatkowy czas, zanim obciążenia będą dostępne w trybie online. Po zaktualizowaniu każdego stojaka, proces aktualizacji zostaje zakończony, a klaster powraca do stanu Running.

Kroki uruchamiania uaktualnienia środowiska uruchomieniowego klastra znajdują się tutaj.

Strategie uaktualniania środowiska uruchomieniowego

Każda z opisanych strategii zapewnia użytkownikom różne mechanizmy kontroli dotyczące sposobu i sposobu uaktualniania stojaków obliczeniowych. Te wartości mają zastosowanie tylko do serwerów obliczeniowych, a nie serwerów zarządzania. Każda strategia używa elementu thresholdType i thresholdValue do zdefiniowania liczby lub procent pomyślnie uaktualnionych serwerów obliczeniowych w stojaku przed przejściem do następnego stojaka.

Wartości progowe to obliczenia wykonywane podczas uaktualniania, aby określić liczbę serwerów obliczeniowych dostępnych po ukończeniu uaktualniania.

Stojak według stojaka

Domyślne zachowanie aktualizacji czasu wykonywania polega na sekwencyjnym przechodzeniu przez każdy stojak, aż zostanie objęta cała lokalizacja, w miarę spełniania progów.

Wstrzymywanie stojaka

Ta strategia wstrzyma uaktualnienie po zakończeniu aktualizacji w szafie rackowej. Następny rack nie rozpocznie się, dopóki klient nie wykona API uaktualnienia.

Szczegółowe informacje na temat uruchamiania uaktualnienia z wstrzymaniem operacji rack znajdują się tutaj.

Obciążenia tenantów w ramach systemu Nexus podczas aktualizacji środowiska uruchomieniowego klastra

Podczas uaktualniania środowiska uruchomieniowego węzły klastra Nexus Kubernetes działające na serwerach zaplanowanych do aktualizacji są zablokowane, opróżniane, a następnie bezpieczne wyłączane przed rozpoczęciem uaktualniania. Odgradzanie węzła uniemożliwia zaplanowanie na nim nowych zasobników, podczas gdy opróżnianie węzła pozwala zasobnikom z obciążeniami dzierżawcy przenieść się na inne dostępne węzły, minimalizując zakłócenia usług. Skuteczność opróżniania zależy od dostępnej pojemności w klastrze. Jeśli klaster jest w pobliżu pełnej pojemności i nie ma miejsca na relokację zasobników, te zasobniki wchodzą w stan Oczekiwanie po opróżnieniu.

Po zakończeniu kroków kordonu i opróżniania węzeł zostanie zamknięty w ramach procesu uaktualniania. Po uaktualnieniu serwera baremetal, węzeł zostanie ponownie uruchomiony, ponownie dołączy do klastra i zostanie odblokowany, co umożliwi ponowne zaplanowanie podów na nim.

W przypadku maszyn wirtualnych Nexus proces jest podobny. Maszyny wirtualne są zamykane przed uaktualnieniem serwera baremetal i automatycznie ponownie uruchamiane po powrocie serwera do trybu online.

Każdemu węzłowi klastra dzierżawcy przysługuje do 20 minut na zakończenie procesu opróżniania. Po tym oknie uaktualnienie serwera będzie kontynuowane niezależnie od ukończenia opróżniania w celu zapewnienia postępu. Serwery są uaktualniane jeden stojak naraz, a uaktualnienia wykonywane równolegle w tym samym stojaku. Uaktualnienie serwera nie czeka na przejście zasobów dzierżawy do trybu online przed kontynuowaniem uaktualniania środowiska uruchomieniowego innych serwerów w stojaku. Oprócz limitu czasu opróżniania istnieje 10-minutowy limit czasu przydzielony dla zamykania maszyn wirtualnych. Takie podejście gwarantuje, że maksymalny czas oczekiwania dla każdego stojaka pozostaje 30 minut, związany wyłącznie z procedurą wyłączania, opróżniania i zamykania kordonu, a nie z ogólną procedurą aktualizacji.

Należy pamiętać, że po uaktualnieniu środowiska uruchomieniowego mogą wystąpić przypadki, że węzeł klastra Kubernetes Nexus pozostaje odizolowany. W takim scenariuszu należy zlokalizować węzły niekordonowe, wykonując następujące polecenie.

az networkcloud baremetalmachine list -g $mrg --subscription $sub --query "sort_by([].{name:name,kubernetesNodeName:kubernetesNodeName,location:location,readyState:readyState,provisioningState:provisioningState,detailedStatus:detailedStatus,detailedStatusMessage:detailedStatusMessage,powerState:powerState,tags:tags.Status,machineRoles:join(', ', machineRoles),cordonStatus:cordonStatus,createdAt:systemData.createdAt}, &name)" 
--output table

Operacje zestawu kluczy BareMetalMachine (BMM) podczas uaktualniania środowiska uruchomieniowego klastra

Po zaktualizowaniu serwera do nowego systemu operacyjnego należy ponownie skonfigurować zestawy kluczy BMM w nowym oprogramowaniu. Ten proces rozpoczyna się po zakończeniu uaktualniania środowiska uruchomieniowego dla wystąpienia. Serwery, które nie zostały jeszcze poddane uaktualnieniu środowiska uruchomieniowego, nadal mogą być dostępne za pośrednictwem zestawu kluczy programu BMM. Jeśli podczas uaktualniania wymagany jest dostęp do maszyny, użytkownik konsoli jest dostępny.

Serwery nie zostały pomyślnie uaktualnione

Serwer pozostaje niedostępny w przypadku niepowodzenia uaktualnienia lub udostępnienia z powodu możliwego problemu ze sprzętem w trakcie ponownego uruchamiania lub problemu z cloud-init (sieć, chronyd itp.). Należy usunąć istniejący problem, a następnie przeprowadzić wymianę lub reinstalację systemu na maszynie bare-metal. Ręczne usunięcie izolacji serwera nie rozwiąże problemów.