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

1. Instalacja interfejsu wiersza polecenia platformy Azure musi być zainstalowana.
2. Rozszerzenie interfejsu networkcloud wiersza polecenia jest wymagane. networkcloud Jeśli rozszerzenie nie jest zainstalowane, można go zainstalować, wykonując kroki wymienione tutaj.
3. Dostęp do witryny Azure Portal, aby klaster docelowy został uaktualniony.
4. Musisz zalogować się do tej samej subskrypcji co klaster docelowy za pośrednictwem az login
5. 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.

Znajdowanie dostępnych wersji środowiska uruchomieniowego

Za pośrednictwem portalu

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"

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 będzie pusta.

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"

Uaktualnienie środowiska uruchomieniowego jest długim procesem. Uaktualnienie najpierw uaktualnia węzły zarządzania, a następnie sekwencyjnie stojak według stojaka 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 obciążenia we wszystkich innych stojakach nie będą mieć wpływu. Zachęcamy do rozważenia umieszczania obciążeń w świetle tego projektu implementacji.

Uaktualnienie wszystkich węzłów trwa wiele godzin, ale może potrwać więcej, jeśli inne procesy, takie jak aktualizacje oprogramowania układowego, również są częścią uaktualnienia. Ze względu na długość procesu uaktualniania zaleca się okresowe sprawdzanie stanu szczegółów klastra dla 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"

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 elementy BMM w każdym stojaku można sprawdzić pod kątem stanu. Przykład tej funkcji znajduje się w sekcji referencyjnej w obszarze Role maszyny BareMetal.

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>

Wymagane argumenty:

• typ strategii: definiuje strategię aktualizacji. W takim przypadku "Rack" oznacza, że aktualizacje są wykonywane w stojaku po stojaku. Wartość domyślna to "Rack"
• typ progu: określa sposób obliczania progu w jednostkach zdefiniowanych przez strategię. Wartość domyślna to "PercentSuccess".
• threshold-value: wartość progowa liczbowa używana do oceny aktualizacji. Wartość domyślna to 80.

Argumenty opcjonalne:

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

Przykładowe użycie polecenia jest następujące:

az networkcloud cluster update --name "cluster01" --resource-group "cluster01-rg" --update-strategy strategy-type="Rack" threshold-type="PercentSuccess" threshold-value=70 max-unavailable=16 wait-time-minutes=15

Po pomyślnym wykonaniu polecenia określone wartości updateStrategy zostaną zastosowane do klastra:

  "updateStrategy": {
      "maxUnavailable": 16,
      "strategyType": "Rack",
      "thresholdType": "PercentSuccess",
      "thresholdValue": 70,
      "waitTimeMinutes": 15,
    },

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 określić, kiedy tak jest, przeglądając dzienniki klastra, szczegółowy komunikat i szczegółowy komunikat o stanie. Jeśli wystąpiło przekroczenie limitu czasu, zauważylibyśmy, że klaster jest stale uzgadniany przez ten sam czas w nieskończoność, a nie w przyszłości. 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ł błąd sprzętowy podczas uaktualniania, uaktualnienie środowiska uruchomieniowego będzie kontynuowane tak długo, jak długo 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 nie powiodło się, ponieważ progi nie zostały spełnione dla węzłów obliczeniowych i kontrolnych, ponowne wykonanie uaktualnienia środowiska uruchomieniowego może być konieczne 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 uaktualnić do nowej wersji środowiska uruchomieniowego, prześlij nowe żądanie uaktualnienia klastra i uaktualnij 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 przejdzie w stan Upgrading W przypadku awarii uaktualnienia środowiska uruchomieniowego ze względów związanych z zasobami klaster przejdzie do Failed stanu aprowizacji. Ten stan może być połączony z cyklem życia składników związanych z klastrem (np. StorageAppliance) i może być konieczne diagnozowanie niepowodzenia z pomocą techniczną firmy Microsoft.