Uaktualnianie środowiska uruchomieniowego klastra z poziomu interfejsu wiersza polecenia platformy Azure

W tym przewodniku z instrukcjami opisano kroki instalowania wymaganego interfejsu wiersza polecenia platformy Azure i rozszerzeń wymaganych do interakcji z operatorem Nexus.

Wymagania wstępne

• Instalacja interfejsu wiersza polecenia platformy Azure musi być zainstalowana.
• Rozszerzenie interfejsu networkcloud wiersza polecenia jest wymagane. networkcloud Jeśli rozszerzenie nie jest zainstalowane, można go zainstalować, wykonując kroki wymienione tutaj.
• Dostęp do witryny Azure Portal, aby klaster docelowy został uaktualniony.
• Musisz zalogować się do tej samej subskrypcji co klaster docelowy za pośrednictwem az login
• Klaster docelowy musi znajdować się w stanie uruchomienia ze wszystkimi węzłami płaszczyzny sterowania w dobrej kondycji i 80% węzłów obliczeniowych w stanie uruchomionym i w dobrej kondycji.

Sprawdzanie bieżącej wersji środowiska uruchomieniowego

Sprawdź bieżącą wersję środowiska uruchomieniowego klastra przed uaktualnieniem: Jak sprawdzić bieżącą wersję środowiska uruchomieniowego klastra.

Znajdowanie dostępnych wersji środowiska uruchomieniowego

Za pośrednictwem witryny Azure Portal

Aby znaleźć dostępne wersje środowiska uruchomieniowego z możliwością uaktualnienia, przejdź do klastra docelowego w witrynie Azure Portal. W okienku przeglądu klastra przejdź do karty Dostępne wersje uaktualnienia.

Na karcie Dostępne wersje uaktualnienia możemy wyświetlić różne wersje klastra, które są obecnie dostępne do uaktualnienia. Operator może wybrać z listy docelowych wersji środowiska uruchomieniowego. Po wybraniu polecenia przejdź do uaktualnienia klastra.

Za pośrednictwem interfejsu wiersza polecenia platformy Azure

Dostępne uaktualnienia można pobierać za pośrednictwem interfejsu wiersza polecenia platformy Azure:

az networkcloud cluster show --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--subscription <subscriptionID>

W danych wyjściowych możesz znaleźć availableUpgradeVersions właściwość i spojrzeć na targetClusterVersion pole:

  "availableUpgradeVersions": [
    {
      "controlImpact": "True",
      "expectedDuration": "Upgrades may take up to 4 hours + 2 hours per rack",
      "impactDescription": "Workloads will be disrupted during rack-by-rack upgrade",
      "supportExpiryDate": "2023-07-31",
      "targetClusterVersion": "3.3.0",
      "workloadImpact": "True"
    }
  ],

Jeśli nie ma dostępnych uaktualnień klastra, lista jest pusta.

Konfigurowanie parametrów progu obliczeniowego na potrzeby uaktualniania środowiska uruchomieniowego przy użyciu metody updateStrategy klastra

Następujące polecenie interfejsu wiersza polecenia platformy Azure służy do konfigurowania parametrów progu obliczeniowego dla uaktualnienia środowiska uruchomieniowego:

az networkcloud cluster update /
--name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value="<thresholdValue>" max-unavailable=<maxNodesOffline> /
wait-time-minutes=<waitTimeBetweenRacks> /
--subscription <subscriptionID>

Wymagane parametry:

• typ strategii: definiuje strategię aktualizacji. Może to być "Rack" (Rack by Rack) LUB "PauseAfterRack" (Uaktualnij jeden stojak naraz, a następnie poczekaj na potwierdzenie przed przejściem do następnego stojaka. Domyślna wartość to Rack. Aby przeprowadzić uaktualnienie środowiska uruchomieniowego klastra przy użyciu strategii "PauseRack", wykonaj kroki opisane w temacie Uaktualnianie środowiska uruchomieniowego klastra ze strategią wstrzymania stojaka
• typ progu: określa sposób obliczania progu w jednostkach zdefiniowanych przez strategię. Może to być "PercentSuccess" wartość OR "CountSuccess". Domyślna wartość to PercentSuccess.
• threshold-value: wartość progowa liczbowa używana do oceny aktualizacji. Domyślna wartość to 80.

Parametry opcjonalne:

• maksymalna niedostępność: maksymalna liczba węzłów roboczych, które mogą być w trybie offline, czyli uaktualniony stojak naraz. Domyślna wartość to 32767.
• wait-time-minutes: Opóźnienie lub okres oczekiwania przed aktualizacją stojaka. Domyślna wartość to 15.

Poniższy przykład dotyczy klienta korzystającego ze strategii Rack by Rack z powodzeniem procentowym 60% i 1-minutową przerwą.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="PercentSuccess" /
threshold-value=60 wait-time-minutes=1 /
--subscription <subscriptionID>

Sprawdź aktualizację:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 60,
      "waitTimeMinutes": 1

W tym przykładzie, jeśli aprowizacja węzłów obliczeniowych w stojaku nie powiedzie się (na stojaku według stojaka), wdrożenie klastra zakończy się niepowodzeniem. Jeśli pomyślnie aprowizowana jest co najmniej 60% węzłów obliczeniowych, wdrożenie klastra zostanie przeniesione do następnego stojaka węzłów obliczeniowych.

Poniższy przykład dotyczy klienta korzystającego ze strategii Rack by Rack z typem progu CountSuccess 10 węzłów na stojak i 1-minutową przerwą.

az networkcloud cluster update --name "<clusterName>" /
--resource-group "<resourceGroup>" /
--update-strategy strategy-type="Rack" threshold-type="CountSuccess" /
threshold-value=10 wait-time-minutes=1 /
--subscription <subscriptionID>

Sprawdź aktualizację:

az networkcloud cluster show --resource-group "<resourceGroup>" /
--name "<clusterName>" /
--subscription <subscriptionID>| grep -a5 updateStrategy

      "strategyType": "Rack",
      "thresholdType": "CountSuccess",
      "thresholdValue": 10,
      "waitTimeMinutes": 1

W tym przykładzie, jeśli aprowizacja w stojaku nie powiedzie się (na podstawie stojaka według stojaka) mniej niż 10 węzłów obliczeniowych, wdrożenie klastra zakończy się niepowodzeniem. Jeśli pomyślnie aprowizowana jest co najmniej 10 węzłów obliczeniowych, wdrożenie klastra zostanie przeniesione do następnego stojaka węzłów obliczeniowych.

Uwaga

update-strategy nie można zmienić po rozpoczęciu uaktualniania środowiska uruchomieniowego klastra. Po ustawieniu wartości progowej poniżej 100% możliwe jest, że wszystkie węzły w złej kondycji nie zostaną uaktualnione, ale stan "Klaster" nadal może wskazywać, że uaktualnienie zakończyło się pomyślnie. Aby rozwiązać problemy z maszynami bez systemu operacyjnego, zapoznaj się z tematem Rozwiązywanie problemów z serwerem Nexus operatora platformy Azure

Uaktualnianie środowiska uruchomieniowego klastra przy użyciu interfejsu wiersza polecenia

Aby przeprowadzić uaktualnienie środowiska uruchomieniowego, użyj następującego polecenia interfejsu wiersza polecenia platformy Azure:

az networkcloud cluster update-version --cluster-name "<clusterName>" /
--target-cluster-version "<versionNumber>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

Uaktualnienie środowiska uruchomieniowego jest długim procesem. Uaktualnienie najpierw uaktualnia węzły zarządzania, a następnie sekwencyjnie rack dla węzłów roboczych. Uaktualnienie jest uważane za zakończone, gdy 80% węzłów roboczych na stojak i 100% węzłów zarządzania zostało pomyślnie uaktualnionych. Może to mieć wpływ na obciążenia, gdy węzły robocze w stojaku są w trakcie uaktualniania, jednak nie ma to wpływu na obciążenia we wszystkich innych stojakach. Zachęcamy do rozważenia umieszczania obciążeń w świetle tego projektu implementacji.

Uaktualnianie wszystkich węzłów trwa wiele godzin w zależności od liczby stojaków dla klastra. Ze względu na długość procesu uaktualniania stan szczegółów klastra powinien być okresowo sprawdzany pod kątem bieżącego stanu uaktualnienia. Aby sprawdzić stan uaktualnienia, sprawdź szczegółowy stan klastra. To sprawdzenie można wykonać za pośrednictwem portalu lub az CLI.

Aby wyświetlić stan uaktualnienia za pośrednictwem witryny Azure Portal, przejdź do docelowego zasobu klastra. Na ekranie Przegląd klastra wyświetlany jest szczegółowy stan wraz ze szczegółowym komunikatem o stanie.

Uaktualnienie klastra jest w toku, gdy parametr detailedStatus jest ustawiony na Updating i szczegółoweStatusMessage pokazuje postęp uaktualniania. Niektóre przykłady postępu uaktualniania pokazane w szczegółowymStatusMessage to Waiting for control plane upgrade to complete..., Waiting for nodepool "<rack-id>" to finish upgrading...itp.

Uaktualnianie klastra zostało ukończone, gdy parametr detailedStatus jest ustawiony na Running , a element detailedStatusMessage wyświetla komunikat Cluster is up and running

Aby wyświetlić stan uaktualnienia za pośrednictwem interfejsu wiersza polecenia platformy Azure, użyj polecenia az networkcloud cluster show.

az networkcloud cluster show --cluster-name "<clusterName>" /
--resource-group "<resourceGroupName>" /
--subscription <subscriptionID>

Dane wyjściowe powinny być informacjami klastra docelowego, a szczegółowy komunikat o stanie i stanie klastra powinien być obecny. Aby uzyskać bardziej szczegółowe informacje na temat postępu uaktualniania, poszczególne węzły w każdym stojaku można sprawdzić pod kątem stanu. Przykład sprawdzania stanu znajduje się w sekcji referencyjnej w obszarze Role maszyny BareMetal.

Często zadawane pytania

Identyfikowanie uaktualnienia klastra zablokowanego/zablokowanego

Podczas uaktualniania środowiska uruchomieniowego uaktualnienie może zakończyć się niepowodzeniem, ale stan szczegółów odzwierciedla, że uaktualnienie jest nadal w toku. Ponieważ ukończenie uaktualnienia środowiska uruchomieniowego może zająć bardzo dużo czasu, obecnie nie określono ustawionej długości limitu czasu. W związku z tym zaleca się również okresowe sprawdzanie stanu szczegółów klastra i dzienników w celu ustalenia, czy uaktualnienie jest na czas nieokreślony, próbując uaktualnić.

Możemy zidentyfikować indefinitely attempting to upgrade sytuację, przeglądając dzienniki klastra, szczegółowy komunikat i szczegółowy komunikat o stanie. Jeśli wystąpi przekroczenie limitu czasu, zauważylibyśmy, że klaster jest stale uzgadniany przez ten sam czas w nieskończoność i nie przechodzi do przodu. W tym miejscu zalecamy sprawdzenie dzienników klastra lub skonfigurowanie usługi LAW, aby sprawdzić, czy wystąpił błąd, czy konkretne uaktualnienie powoduje brak postępu.

Awaria sprzętowa nie wymaga ponownego wykonania uaktualnienia

Jeśli wystąpi awaria sprzętowa podczas uaktualniania, uaktualnienie środowiska uruchomieniowego będzie kontynuowane tak długo, jak są spełnione określone progi dla węzłów obliczeniowych i zarządzania/sterowania. Po naprawieniu lub zastąpieniu maszyny zostanie ona aprowizowana przy użyciu systemu operacyjnego bieżącego środowiska uruchomieniowego platformy, który zawiera docelową wersję środowiska uruchomieniowego.

Jeśli wystąpi awaria sprzętowa, a uaktualnienie środowiska uruchomieniowego zakończy się niepowodzeniem, ponieważ progi nie zostały spełnione dla węzłów obliczeniowych i kontrolnych, może być konieczne ponowne wykonanie uaktualnienia środowiska uruchomieniowego. W zależności od tego, kiedy wystąpił błąd i stan poszczególnych serwerów w stojaku. Jeśli stojak został zaktualizowany przed awarią, uaktualniona wersja środowiska uruchomieniowego zostanie użyta podczas ponownego aprowizacji węzłów. Jeśli specyfikacja stojaka nie została zaktualizowana do uaktualnionej wersji środowiska uruchomieniowego przed awarią sprzętu, maszyna zostanie aprowizowana przy użyciu poprzedniej wersji środowiska uruchomieniowego. Aby przeprowadzić uaktualnienie do nowej wersji środowiska uruchomieniowego, prześlij nowe żądanie uaktualnienia klastra. Uaktualniane są tylko węzły z poprzednią wersją środowiska uruchomieniowego. Hosty, które zakończyły się powodzeniem w poprzedniej akcji uaktualnienia, nie będą.

Po uaktualnieniu środowiska uruchomieniowego klaster ma stan aprowizacji "Niepowodzenie"

Podczas uaktualniania środowiska uruchomieniowego klaster wprowadza stan Upgrading. Jeśli uaktualnienie środowiska uruchomieniowego zakończy się niepowodzeniem Failed , klaster przejdzie w stan aprowizacji. Składniki infrastruktury (np. urządzenie magazynu) mogą powodować błędy podczas uaktualniania. W niektórych scenariuszach może być konieczne diagnozowanie niepowodzenia z pomocą techniczną firmy Microsoft.