Melakukan upgrade dalam deployment multizona

Dalam deployment multi-zona, zona diupgrade satu per satu dan secara independen. Tidak ada orkestrasi upgrade global di seluruh zona. IO harus melakukan upgrade di setiap zona untuk organisasi yang ingin diupgrade ke versi baru. Akibatnya, organisasi di zona yang berbeda dapat menggunakan versi yang berbeda pada waktu tertentu.

Urutan upgrade yang diuraikan di halaman ini adalah mengupgrade org root serta semua org tenant dalam satu zona sebelum beralih ke zona lain. Resource global diupgrade di akhir, setelah semua zona diupgrade.

Halaman ini menjelaskan langkah-langkah untuk melanjutkan upgrade multi-zona Google Distributed Cloud (GDC) air-gapped dengan memberikan jenis informasi berikut:

• Akses yang diperlukan dan cara mendapatkannya.
• Alat yang Anda butuhkan.
• Langkah-langkah yang harus dilakukan sebelum Anda melakukan upgrade.
• Cara dan urutan melakukan upgrade untuk berbagai komponen Distributed Cloud.

Penting: Kecuali dinyatakan lain, petunjuk ini menjelaskan cara mengupgrade dari tingkat rilis saat ini ke tingkat rilis terbaru yang tersedia, seperti ke 1.x.y. Misalnya, jika Anda bekerja dari rilis 1.x.0 dan petunjuk ini memberikan informasi upgrade yang menargetkan 1.x.2, Anda tidak perlu mengupgrade ke 1.x.1 terlebih dahulu. Komponen apa pun yang memerlukan upgrade ke tingkat menengah akan memiliki persyaratan dan detail yang dinyatakan dengan jelas di bagian masing-masing.

Daftar berikut menentukan setiap komponen upgrade:

Versi target: Gunakan versi target yang sama untuk semua zona.

Satu per satu: Upgrade satu zona dalam satu waktu. Sebelum upgrade dipicu di satu zona, pastikan tidak ada zona lain yang menjalankan upgrade.

Resource global: Ditentukan sebagai resource Kubernetes yang di-deploy di kube-apiserver global, bukan resource zonal yang memiliki satu salinan per zona. Resource global mengikuti siklus proses yang berbeda. Perhatikan bahwa mereka perlu diupgrade di akhir, hanya satu kali.

Persiapan

URL disediakan untuk mengakses di luar lingkungan yang terisolasi dari internet.

Sebelum memulai upgrade, siapkan hal berikut:

• Jalur ke file kubeconfig yang Anda peroleh dengan menjalankan gdcloud auth login ke cluster admin root.

  Penting: Anda harus memiliki jalur kubeconfig sebelum dapat melanjutkan.

• Artefak rilis baru, didownload dan ditransfer dengan aman ke komputer Anda. Ikuti langkah-langkah yang diberikan di Mengirim artefak ke container registry.

• Mesin host untuk menjalankan upgrade manual, dengan file kubeconfig cluster admin root di mesin.

• Setiap Masalah Umum untuk upgrade DARI versi tersebut akan diatasi sebelum memulai upgrade. Khusus untuk upgrade dari 1.13.1, pastikan masalah berikut telah diselesaikan:

  • VM yang tidak memiliki ruang penyimpanan yang tersisa di perangkat

Membuat laporan kepatuhan

Laporan kepatuhan mencantumkan Organisasi yang:

• tidak lagi didukung
• tidak menginstal patch keamanan penting

Pembuatan laporan kepatuhan adalah langkah opsional dan memerlukan IO yang diautentikasi yang memiliki organization-admin role. Untuk membuat laporan, jalankan perintah berikut:

  gdcloud system upgrade report-compliance

Untuk mengetahui informasi selengkapnya tentang persyaratan persiapan, lihat bagian Prasyarat.

Identity and Access Management

Sebelum memulai upgrade, di setiap zona:

1. Dapatkan file kubeconfig dengan menjalankan gdcloud auth login ke cluster admin root dan semua cluster admin org.

2. Ikuti petunjuk dalam runbook Proses elevasi akses dan hak istimewa IAM-R0005 untuk menambahkan:

   1. ClusterRoleBinding dengan cluster-admin ClusterRole di cluster admin root setiap zona
   2. org admin cluster sehingga akses admin sementara diperoleh.

Menjeda upgrade resource global di semua zona

Gunakan file kubeconfig yang diperoleh untuk menjeda semua upgrade resource global di setiap zona.

# Pause upgrades to global root admin resources.
kubectl patch kubeapiserver global-root-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"LocalOnly"}}' --type=merge --kubeconfig=ROOT_ADMIN_KUBECONFIG

# Pause upgrades to global org admin resources.
kubectl patch kubeapiserver global-org-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"LocalOnly"}}' --type=merge --kubeconfig=ORG_MGMT_API_KUBECONFIG

Mengupgrade org root global

Mengupgrade org root global pada tingkat tinggi mencakup langkah-langkah berikut:

1. Upgrade org root di semua zona. Setiap zona diupgrade satu per satu.

   Penting: Mulai upgrade dengan zona utama StorageGrid, lalu ulangi untuk semua zona lain dalam deployment. Urutan ini diperlukan agar penyimpanan objek berfungsi dengan baik.

   Periksa apakah zona saat ini adalah zona primer. Perintah berikut menampilkan "true" di zona utama dan tidak menampilkan apa pun di zona non-utama.

   kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
   

2. Upgrade komponen yang memerlukan koordinasi lintas zona.

3. Mengupgrade resource admin root global.

Pemeriksaan sebelum upgrade

Upgrade zona satu per satu. Sebelum memulai upgrade org di satu zona, hubungkan ke semua zona lainnya dan jalankan perintah berikut untuk memastikan perintah menampilkan status siap di semua zona. Jika ada zona yang melaporkan bahwa zona tersebut belum siap, jangan lanjutkan upgrade. Periksa org di zona tersebut untuk mendiagnosis masalah.

ORG_NAME=root

[[ $(kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get org ${ORG_NAME} -n gpc-system -ojsonpath='{.status.conditions[?(@.type=="Ready")].status}') == 'True' ]] && echo ready || echo not ready

1. Mendownload dan menyalin paket update

Petunjuk ini menjelaskan cara memulai:

• Download paket update ke perangkat yang dapat diakses internet untuk disalin ke drive USB.
• Salin paket update dari drive USB ke lingkungan yang terisolasi dari internet.

Untuk konteks tambahan, lihat Mendownload file untuk mendownload detail distribusi Distributed Cloud, dan Transfer download untuk mengetahui informasi tentang perangkat penyimpanan portabel yang Anda gunakan untuk mentransfer file ke lingkungan yang terisolasi.

1. Bekerja sama dengan POC Google Anda untuk memutuskan apakah upgrade ditujukan untuk deployment Distributed Cloud yang dioperasikan partner, sehingga harus menggunakan file rilis model partner.

   PARTNER_OPERATED="IS_PARTNER_OPERATED"
   if [[ ${PARTNER_OPERATED:?} == "true" ]]; then
     RELEASE_SUFFIX="_partner"
     export GCS_BUCKET=private-cloud-release-partner
   else
     RELEASE_SUFFIX=""
     export GCS_BUCKET=private-cloud-release
   fi
   

2. Download paket update ke drive USB Anda dari komputer yang dapat mengakses internet. Gunakan detail versi dan ringkasan yang diberikan oleh kontak Google Anda.

   1. Jalankan gcloud auth login untuk mengakses bucket Cloud Storage.

   2. Jalankan skrip dengan --skip-unzip untuk mengambil paket update dan skrip downloader ke direktori saat ini, seperti /home/download.

      VERSION=VERSION
      DOWNLOADER=gdch-downloader-prod${RELEASE_SUFFIX}-$VERSION.sh
      gcloud storage cp "gs://${GCS_BUCKET:-private-cloud-release}/$VERSION/$DOWNLOADER*" .
         PUBLIC_KEY=$(cat <<-PUBEND
      -----BEGIN PUBLIC KEY-----
      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEn46iVSyFXsvuKLZ4dVOr2AqlXDnR
      5cKztkpraexHDxn/ozq03EvrdkRmZkSACFfcaEFyitpraidgAx8sPjvzXQ==
      -----END PUBLIC KEY-----
      PUBEND
      )
      echo "${PUBLIC_KEY}" > "key.pub" openssl dgst -sha256 -verify "key.pub" -signature "${DOWNLOADER}.sig" ${DOWNLOADER} && chmod +x $DOWNLOADER && ./$DOWNLOADER --skip-unzip
      

   3. Jika Anda mengupgrade dengan file rilis model partner, ikuti petunjuknya untuk menyiapkan paket software bagi distribusi model partner.

      Catatan: lewati langkah ini jika Anda tidak menggunakan file rilis model partner untuk upgrade.

3. Salin skrip downloader dan direktori gdch ke USB drive Anda.

4. Salin update ke OCIT dari drive USB Anda. Tempatkan file di tempat yang serupa seperti /home/download/.

5. Tentukan ulang variabel ini di OCIT dan ekstrak pembaruan:

   cd /root
   VERSION=VERSION
   DOWNLOADER=gdch-downloader-prod${RELEASE_SUFFIX}-$VERSION.sh
   PUBLIC_KEY=$(cat <<-PUBEND
   -----BEGIN PUBLIC KEY-----
   MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEn46iVSyFXsvuKLZ4dVOr2AqlXDnR
   5cKztkpraexHDxn/ozq03EvrdkRmZkSACFfcaEFyitpraidgAx8sPjvzXQ==
   -----END PUBLIC KEY-----
   PUBEND
   )
   echo "${PUBLIC_KEY}" > "key.pub" openssl dgst -sha256 -verify "key.pub" -signature "${DOWNLOADER}.sig" ${DOWNLOADER} && chmod +x $DOWNLOADER && ./$DOWNLOADER --skip-download
   

6. Pengunduh akan mengekstrak rilis ke gdch/full-release-1.2.0-gdch.243 (mis./home/download/gdch/full-release-1.2.0-gdch.243). Tetapkan variabel ini ke jalur lengkap:

   export ARTIFACTS_ROOT='/home/download/gdch/full-release-RELEASE_VERSION'-gdch.BUILD_NUMBER'
   

2. Mengonfigurasi upgrade artifact registry

Agar berhasil melakukan upgrade, Anda harus menyelesaikan hal berikut:

Kirim artefak ke container registry

1. Tetapkan KUBECONFIG ke file kubeconfig untuk cluster admin root.

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   

2. Buat ClusterRoleBindings yang diperlukan:

   kubectl create clusterrolebinding io-upgrade-admin --clusterrole=upgrade-admin-dc --user=USER_EMAIL
   
   kubectl create clusterrolebinding io-upgrade-debugger --clusterrole=upgrade-debugger --user=USER_EMAIL
   

3. Buat RoleBindings yang diperlukan:

   kubectl create rolebinding io-system-artifact-management-secrets-admin --role=system-artifact-management-secrets-admin --user=USER_EMAIL -n anthos-creds
   
   kubectl create rolebinding io-system-artifact-management-admin --role=system-artifact-management-admin --user=USER_EMAIL -n gpc-system
   
   kubectl create rolebinding io-dnssuffix-viewer --role=dnssuffix-viewer --user=USER_EMAIL -n gpc-system
   

4. Buat RoleBindings yang diperlukan untuk mengirimkan paket OCI:

   kubectl create rolebinding infrastructure-operator-sar-harbor-admin --user=gdch-infra-operator-USER_EMAIL --role=sar-harbor-admin -n gpc-system
   

   Output-nya akan terlihat seperti ini:

   rolebinding.rbac.authorization.k8s.io/infrastructure-operator-sar-harbor-admin created
   

5. Gunakan petunjuk di Mengubah ukuran penyimpanan Artifact Registry untuk melakukan hal berikut:

   1. Periksa penggunaan penyimpanan Artifact Registry di cluster admin dan pastikan ada ruang yang cukup untuk artefak yang ingin Anda kirim.
   2. Jika Anda perlu menambah ruang yang tersedia, gunakan langkah-langkah yang diberikan dalam artikel Mengubah ukuran penyimpanan Artifact Registry.

6. Siapkan konfigurasi Docker:

   cp ${ARTIFACTS_ROOT}/docker-credential-gdcloud /usr/bin
   

   Catatan: Selalu pastikan biner ini ada sebelum Anda menjalankan load-oci.

7. Konfigurasi Docker agar memercayai paket trust-store.

   REGISTRY=$(kubectl get harborcluster harbor -n harbor-system -o jsonpath='{.spec.externalURL}' 2>/dev/null);
   if [[ -z "$REGISTRY" ]]; then echo "Harbor external URL not found" >&2; exit 1; fi;
   
   HOST=$(echo "$REGISTRY" | sed 's#https://##');
   if [[ -z "$HOST" ]]; then echo "Invalid registry URL" >&2; exit 1; fi;
   
   DIR="/etc/docker/certs.d/$HOST"; FILE="$DIR/ca.crt"; mkdir -p "$DIR"; chmod 755 "$DIR";
   if [[ ! -f "$FILE" ]]; then
      CERT=$(kubectl get secret trust-store-internal-only -n istio-system -o jsonpath='{.data.ca\.crt}' 2>/dev/null);
      if [[ -z "$CERT" ]]; then echo "Certificate secret not found" >&2;
      exit 1;
      fi;
      echo "$CERT" | base64 -d > "$FILE"; chmod 644 "$FILE";
   else echo "Certificate $FILE already exists"; fi
   

8. Muat artefak ke dalam registry artefak di cluster admin root:

   export VERSION=VERSION
   export KUBECONFIG=KUBECONFIG_PATH
   export ARTIFACTS_ROOT=/home/download/gdch/full-release-VERSION
   export PACKAGE_VALIDATION_ROOT_CERT=PACKAGE_VALIDATION_ROOT_CERT_PATH
   
   ${ARTIFACTS_ROOT}/gdcloud auth configure-docker
   ${ARTIFACTS_ROOT}/gdcloud system container-registry load-oci ${ARTIFACTS_ROOT}/oci --pv-root-cert-path=PACKAGE_VALIDATION_ROOT_CERT_PATH --kubeconfig=KUBECONFIG_PATH --use-ip-port=true --show-progress=false
   

   Ganti kode berikut:

   • VERSION: versi rilis Distributed Cloud. Contoh, 1.x.y-gdch.z.
   • KUBECONFIG_PATH: jalur ke file kubeconfig yang Anda peroleh dengan menjalankan gdcloud auth login di cluster admin root.
   • PACKAGE_VALIDATION_ROOT_CERT_PATH: jalur ke sertifikat root validasi paket. Anda harus menggunakan jalur default ${ARTIFACTS_ROOT}/staging_root_ca_certificate.crt. Pencantuman jalur ini memvalidasi sertifikat kunci rilis yang digunakan oleh validasi paket.

   Jika perintah berhasil, output Anda di akhir akan terlihat mirip dengan contoh ini:

   I0911 04:05:01.755927 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-bg4ck, starting time: 04:05:01.                                                  │·······
   I0911 04:05:02.002637 3463529 monitor.go:100] [2/2] artifacts distributed and [0/0/0] inProgress/failed/stopped after 246.689693ms                                              │·······
   I0911 04:05:02.002723 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-jv5p9, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.039545 3463529 monitor.go:44] Created after 36.820059ms.                                                                                                         │·······
   I0911 04:05:02.039599 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-jv5p9, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.045964 3463529 monitor.go:100] [3/3] artifacts distributed and [0/0/0] inProgress/failed/stopped after 6.360571ms                                                │·······
   I0911 04:05:02.045997 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-bhckh, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.077418 3463529 monitor.go:44] Created after 31.408176ms.                                                                                                         │·······
   I0911 04:05:02.077464 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-bhckh, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.239086 3463529 monitor.go:100] [2/2] artifacts distributed and [0/0/0] inProgress/failed/stopped after 161.610475ms                                              │·······
   I0911 04:05:02.239138 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-xvlbt, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.248366 3463529 monitor.go:44] Created after 9.220575ms.                                                                                                          │·······
   I0911 04:05:02.248415 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-xvlbt, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.532191 3463529 monitor.go:100] [1/1] artifacts distributed and [0/0/0] inProgress/failed/stopped after 283.756574ms                                              │·······
   I0911 04:05:02.532236 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-7k4s4, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.544529 3463529 monitor.go:44] Created after 12.282657ms.                                                                                                         │·······
   I0911 04:05:02.544579 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-7k4s4, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.641252 3463529 monitor.go:100] [1/1] artifacts distributed and [0/0/0] inProgress/failed/stopped after 96.652179ms                                               │·······
   I0911 04:05:02.641332 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-dpj7n, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.645509 3463529 monitor.go:44] Created after 4.169293ms.                                                                                                          │·······
   I0911 04:05:02.645575 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-dpj7n, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.839587 3463529 monitor.go:100] [3/3] artifacts distributed and [0/0/0] inProgress/failed/stopped after 194.004999ms                                              │·······
   I0911 04:05:02.839639 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-fn94p, starting time: 04:05:02.                                                  │·······
   I0911 04:05:02.844001 3463529 monitor.go:44] Created after 4.361378ms.                                                                                                          │·······
   I0911 04:05:02.844034 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-fn94p, starting time: 04:05:02.                                                  │·······
   I0911 04:05:03.041615 3463529 monitor.go:100] [2/2] artifacts distributed and [0/0/0] inProgress/failed/stopped after 197.567981ms                                              │·······
   I0911 04:05:03.041675 3463529 monitor.go:38] Monitoring DistributionPolicy 10.5.23.4-1.12.4.96-4cxxf, starting time: 04:05:03.                                                  │·······
   I0911 04:05:03.047192 3463529 monitor.go:44] Created after 5.499407ms.                                                                                                          │·······
   I0911 04:05:03.047292 3463529 monitor.go:94] Monitoring ManualDistribution 10.5.23.4-1.12.4.96-4cxxf, starting time: 04:05:03.                                                  │·······
   I0911 04:05:03.241688 3463529 monitor.go:100] [76/76] artifacts distributed and [0/0/0] inProgress/failed/stopped after 194.395913ms
   

   Jika output Anda tidak menyerupai contoh ini, ikuti langkah-langkah berikut untuk menyelesaikan masalah yang paling umum:

   • Jika output Anda menyertakan pesan Package validation root certificate requires upgrade!, ganti sertifikat root dengan mengikuti langkah-langkah yang dijelaskan di Mengganti sertifikat validasi paket.
   • Jika load-oci gagal, jalankan kembali operasi. Jika error masih berlanjut, periksa solusi lain yang ditawarkan dalam daftar ini.
   • Jika output Anda menyertakan pesan Error: unable to create k8sclient: Unauthorized, Anda harus melakukan autentikasi lagi. Ulangi langkah persiapan untuk memverifikasi file kubeconfig atau jalankan perintah ${ARTIFACTS_ROOT}/gdcloud auth login dan coba lagi operasi load-oci.
   • Jika output Anda menyertakan pesan UNAUTHORIZED: unauthorized to access repository, berarti Anda tidak memiliki izin yang diperlukan untuk menjalankan perintah load-oci. Naikkan masalah ini untuk mendapatkan peran yang diperlukan untuk menjalankan perintah ini, atau minta pengguna yang memiliki peran yang diperlukan untuk menjalankan perintah ini atas nama Anda.

9. Untuk upgrade dengan file rilis model partner SAJA, ikuti petunjuk untuk memuat paket software untuk distribusi model partner.

10. Verifikasi bahwa objek ReleaseMetadata untuk versi rilis baru ada di cluster admin root:

    kubectl get releasemetadata.artifact.private.gdc.goog VERSION
    

    Ganti VERSION dengan versi rilis Distributed Cloud. Contoh, 1.x.y-gdch.z.

    Contoh output:

    NAME             AGE
    1.x.y-gdch.z     2m
    

11. Pastikan versi baru ada dalam daftar upgrade yang tersedia untuk organisasi root yang akan diupgrade:

    ROOT_NAME=root
    kubectl get organization -n gpc-system ${ROOT_NAME} -ojsonpath='{.status.availableUpgrades}{"\n"}'
    

    Misalnya, 1.x.y-gdch.z, kita mengharapkan output berikut:

    ["1.x.y-gdch.z"]
    

Setelah organisasi root diupgrade ke versi baru, versi tersebut akan tersedia untuk upgrade organisasi tenant.

3. Mengupgrade org root

3.1. Pra-upgrade

1. Tetapkan KUBECONFIG ke file kubeconfig untuk cluster admin root.

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   

2. Buat ClusterRoleBindings yang diperlukan:

   kubectl create clusterrolebinding io-organization-admin --clusterrole=organization-admin --user=USER_EMAIL
   

3. Verifikasi bahwa organisasi root dalam kondisi baik, yang ditunjukkan oleh respons True:

   kubectl get organization -n gpc-system root \
       -ojsonpath='{.status.conditions[?(@.type=="Ready")].status}{"\n"}'
   

   Contoh output:

   True
   

4. Ikuti petunjuk di runbook HSM-P0003 untuk memulai ulang semua HSM.

3.2. Melakukan upgrade otomatis organisasi root

Upgrade harus melalui proses IaC. Upgrade dipicu dengan memperbarui kolom versi di objek OrganizationZonalConfig yang sesuai dari organisasi di zona.

Penting: Sebelum memulai upgrade, periksa apakah file OrganizationZonalConfig ada di repositori IaC di bagian iac/infrastructure/global/orgs/root untuk org root dan zona saat ini. Jika belum, ikuti petunjuk ini untuk membuatnya terlebih dahulu.

1. Perbarui versi dalam file YAML OrganizationZonalConfig. Hapus bagian spec.capacities.workloadServers dalam file jika ada.

   ORG_NAME=root
   ZONE=$(kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get controlplane cp -n mz-system -ojsonpath='{.spec.zone}')
   sed -i 's/version: .*$/version: VERSION/' IAC_REPO_PATH/iac/infrastructure/global/orgs/${ORG_NAME}/${ORG_NAME}-${ZONE}.yaml
   

2. Siapkan dan commit perubahan file.

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

3. Buat permintaan penggabungan.

   git checkout -b ${USERNAME1}-branch
   git -c http.sslVerify=false push -o merge_request.create origin ${USERNAME1}-branch
   

Saat upgrade dimulai, objek OrganizationUpgrade akan dibuat. Pastikan objek OrganizationUpgrade root dibuat di cluster admin root di zona.

kubectl get -n gpc-system organizationupgrade root -o yaml --kubeconfig ROOT_ADMIN_KUBECONFIG

Jika OrganizationUpgrade tidak ditemukan, ikuti runbook IAC-R0001 untuk memecahkan masalah.

3.3. Pemeriksaan pasca-upgrade

1. Verifikasi hasil upgrade:

   1. Periksa objek Organization untuk organisasi root. Pastikan Anda melihat kondisi status READY adalah True:

      kubectl -n gpc-system get organization root
      

      Contoh output:

      NAME   READY
      root   True
      

   2. Pastikan Organization.Status.Version menampilkan string 1.x.y-gdch.z yang sama persis:

      kubectl -n gpc-system get organization root -o jsonpath='{.status.version}{"\n"}'
      

      Contoh output untuk verifikasi:

      1.13.3-gdch.5548
      

2. Periksa kegagalan subkomponen di organisasi root:

   1. Periksa subkomponen yang menampilkan status ReconciliationError atau Reconciling. Arahkan kubeconfig ke ROOT_ADMIN_KUBECONFIG:

      export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
      export CLUSTER_NAMESPACE=root
      echo "Subcomponents with failures"
      kubectl get subcomponent -n ${CLUSTER_NAMESPACE} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") | select(.status.featureDisabled != true) |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'
      echo "Subcomponents still reconciling"
      kubectl get subcomponent -n ${CLUSTER_NAMESPACE} -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "Reconciling") | select(.status.featureDisabled != true) | select( "\(.status)" | contains("PreinstallPending") | not) | "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'
      

   2. Untuk mengetahui error, periksa catatan rilis dan masalah umum untuk mengetahui solusinya , atau hubungi Distributed Cloud untuk mendapatkan pemecahan masalah.

3. Jika pemeriksaan pra-penerbangan atau pemeriksaan pasca-penerbangan dilewati, hapus anotasi setelah upgrade selesai:

   Contoh:

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   kubectl annotate -n gpc-system organization ORG_NAME \
       upgrade.private.gdc.goog/skip-preflight-check-
   

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   kubectl annotate -n gpc-system organization ORG_NAME \
       upgrade.private.gdc.goog/skip-postflight-check-
   

Selesaikan upgrade org root di semua zona

Setelah upgrade selesai di satu zona, sebaiknya periksa apakah zona tersebut masih berfungsi dengan baik sebelum melanjutkan upgrade zona berikutnya.

Ulangi Langkah 1 hingga 3 untuk organisasi root di zona lainnya. Setelah semua zona mengupgrade org. root-nya, lanjutkan ke langkah berikutnya.

4. Mengupgrade resource global

Resource global harus berada di versi terendah dari semua zona. Mulai proses upgrade resource global dengan menghubungkan ke zona anchor dan menjalankan perintah berikut.

# Annotate appropriate versions for all the operable components.
MAP=$(kubectl get kubeapiserver root-admin -n root -ojsonpath='{.metadata.annotations}' --kubeconfig ROOT_ADMIN_KUBECONFIG | jq -r 'to_entries | map("\(.key) \(.value)") | .[] | select(startswith("lcm.private.gdc.goog/oc-version-"))')

echo "${MAP}" | while read KV; do
   SPLIT=(${KV}); KEY=${SPLIT[0]}; VALUE=${SPLIT[1]}
   echo "Annotating global KubeAPIServer with ${KEY}: ${VALUE}"
   kubectl annotate kubeapiserver global-root-admin -n global-kube-system --overwrite ${KEY}=${VALUE} --kubeconfig ROOT_ADMIN_KUBECONFIG
done

# Trigger the global resource upgrade on global root admin.
kubectl annotate kubeapiserver global-root-admin -n global-kube-system --overwrite lcm.private.gdc.goog/paused-remote=false --kubeconfig ROOT_ADMIN_KUBECONFIG
kubectl patch kubeapiserver global-root-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"AllowAll"}}' --type=merge --kubeconfig ROOT_ADMIN_KUBECONFIG

Proses ini mungkin membutuhkan waktu beberapa menit. Verifikasi penyelesaian upgrade resource global dengan menjalankan perintah berikut. Tidak ada kegagalan yang akan dilaporkan dari perintah.

Penting: Verifikasi hanya boleh dilakukan di zona penanda. Zona lainnya akan dijeda dan statusnya mungkin tidak diperbarui.

# Verify that Components are all successfully rolled out on global root admin.
echo "${MAP}" | while read KV; do
   SPLIT=(${KV}); VALUE=${SPLIT[1]}; OC=$(echo ${VALUE} | cut -d- -f1)
   [[ -n ${OC} ]] || continue
   ROLLOUT=$(kubectl get componentrollout ${OC} -n global-kube-system -o json --ignore-not-found --kubeconfig ROOT_ADMIN_KUBECONFIG)
   [[ -n ${ROLLOUT} ]] || continue
   if [[ $(echo ${ROLLOUT} | jq -r '.spec.componentRef.name') != ${VALUE} ]] ; then
      echo "${OC} rollout trigger failed"; continue
   fi
   if [[ $(echo ${ROLLOUT} | jq -r '.status.allSubcomponentsReady') != 'true' ]] ; then
      echo "${OC} rollout completion failed. Use 'kubectl describe componentrollout ${OC} -n global-kube-system --kubeconfig ROOT_ADMIN_KUBECONFIG' to check for error messages."
   fi
done && echo "Global component rollout check finished."

5. Upgrade komponen lintas zona

Di lingkungan multi-zona GDC, komponen tertentu yang dapat dioperasikan memerlukan koordinasi antar-zona untuk menyelesaikan upgrade-nya.

Komponen yang dapat dioperasikan berikut di-upgrade pada langkah ini.

Cakupan	Komponen yang dapat dioperasikan
Infrastruktur	IAC
Infrastruktur	SIEM

Untuk mengupgrade komponen yang dapat dioperasikan IAC, ikuti runbook IAC-R0016.

Untuk mengupgrade komponen yang dapat dioperasikan SIEM, ikuti runbook SIEM-G0008.

6. Upgrade manual untuk Subnet Anycast

Catatan: langkah ini hanya berlaku saat mengupgrade organisasi root global dari versi 1.14.3.

Jalankan skrip berikut untuk menambahkan label yang diperlukan ke subnet anycast di server API root global:

#!/bin/bash

# Description:
# This script ensures that specific Subnet resources in Kubernetes have the
# correct label applied. This is necessary for anycast features to function correctly.
#
# The script is idempotent and can be run multiple times safely.
# It requires the path to a valid global root kubeconfig file as a command-line argument.

# --- Configuration ---
set -o nounset

# The names of the Subnet resources to update.
readonly SUBNET_NAMES=(
  "infra-vpc-anycast-cidr"
  "data-global-anycast-cidr"
  "admin-global-anycast-cidr"
)

# The label that will be applied to the subnets.
readonly LABEL_KEY="ipam.gdc.goog/usage"
readonly LABEL_VALUE="global-anycast-root-range"

# The Kubernetes resource type for the subnets.
readonly SUBNET_RESOURCE_TYPE="subnets"

# Timeout for kubectl commands in seconds.
readonly KUBECTL_TIMEOUT="30s"

log_error() {
  echo "[ERROR] $(date +'%Y-%m-%dT%H:%M:%S%z'): $*" >&2
}

main() {
  # --- Argument Validation ---
  if [[ $# -ne 1 ]]; then
    echo "Usage: $0 <path-to-kubeconfig-file>"
    echo "Example: $0 /root/release/root-admin/global-root-admin-kubeconfig"
    exit 1
  fi

  local KUBECONFIG_PATH="$1"

  if [[ ! -f "${KUBECONFIG_PATH}" ]]; then
      log_error "Kubeconfig file not found at: ${KUBECONFIG_PATH}"
      exit 1
  fi

  if ! command -v kubectl &> /dev/null; then
    log_error "kubectl command not found. Please ensure it is installed and in your system's PATH."
    exit 1
  fi

  if ! command -v timeout &> /dev/null; then
    log_error "timeout command not found. Please ensure 'coreutils' is installed."
    exit 1
  fi

  if ! command -v jq &> /dev/null; then
    log_error "jq command not found. Please ensure it is installed and in your system's PATH."
    exit 1
  fi

  echo "Starting Subnet labeling process using kubeconfig: ${KUBECONFIG_PATH}"

  # --- Pre-flight Check and Data Fetch ---
  echo "Verifying access and fetching all Subnet resources (timeout in ${KUBECTL_TIMEOUT})..."
  local all_subnets_json

  if ! all_subnets_json=$(timeout "${KUBECTL_TIMEOUT}" kubectl get --kubeconfig="${KUBECONFIG_PATH}" "${SUBNET_RESOURCE_TYPE}" --all-namespaces -o json 2>/dev/null); then
      log_error "Failed to list Subnet resources. The command timed out or returned an error. Please check cluster connectivity and permissions."
      exit 1
  fi

  if [[ -z "${all_subnets_json}" ]] || [[ $(jq '.items | length' <<< "${all_subnets_json}") -eq 0 ]]; then
      echo "No subnet resources found in the cluster. Exiting."
      exit 0
  fi
  echo "Access verified. Processing subnets..."

  local processed_count=0
  local found_count=0
  local subnet_regex
  subnet_regex=$(printf "|%s" "${SUBNET_NAMES[@]}")
  subnet_regex="^(${subnet_regex:1})$"

  # jq query to output: namespace  name  label_value (or null)
  echo "${all_subnets_json}" | jq -r ".items[] | [.metadata.namespace, .metadata.name, (.metadata.labels | .[\"${LABEL_KEY}\"] // \"\")] | @tsv" |
  while IFS=$'\t' read -r namespace name current_value; do
    if [[ -z "${name}" ]]; then continue; fi

    if [[ ! "${name}" =~ ${subnet_regex} ]]; then
        continue
    fi

    ((found_count++))
    echo "Found target subnet: '${name}' in namespace '${namespace}'"

    if [[ "${current_value}" == "${LABEL_VALUE}" ]]; then
        echo "  - Subnet already has the correct label. Skipping."
        ((processed_count++))
        continue
    fi

    echo "  - Applying label '${LABEL_KEY}=${LABEL_VALUE}'..."
    if ! timeout "${KUBECTL_TIMEOUT}" kubectl label --kubeconfig="${KUBECONFIG_PATH}" --namespace="${namespace}" "${SUBNET_RESOURCE_TYPE}" "${name}" "${LABEL_KEY}=${LABEL_VALUE}" --overwrite > /dev/null; then
        log_error "Failed to apply label to subnet '${name}' in namespace '${namespace}'. The command timed out or returned an error."
    else
        echo "  - Successfully labeled subnet."
        ((processed_count++))
    fi
  done

  # --- Final Summary ---
  echo "---"
  if [[ ${found_count} -eq 0 ]]; then
    echo "No target anycast subnets were found in the cluster."
  else
    echo "Finished processing. Found ${found_count} and validated ${processed_count} target subnet(s)."
  fi

  echo "Subnet labeling process completed."
}

# Execute the main function with command-line arguments.
main "$@"

Setelah skrip berhasil dijalankan, batalkan solusi anycast manual jika solusi tersebut telah diterapkan sebelumnya.

7. Upgrade manual untuk SyncServer

Komponen yang dapat dioperasikan berikut di-upgrade pada langkah ini.

Cakupan	Komponen yang dapat dioperasikan
Infrastruktur	NTP

Upgrade firmware ini tidak bergantung pada langkah lain dan dapat dilakukan kapan saja.

Cluster hanya memiliki satu SyncServer, sehingga tidak dapat beroperasi dalam mode ketersediaan tinggi. Upgrade akan menyebabkan SyncServer tidak tersedia selama beberapa waktu. Cluster akan terus mencatat waktu menggunakan clock-nya sendiri yang kurang akurat, yang tidak akan menimbulkan efek yang terlihat.

Sebaiknya proses ini diselesaikan dalam satu sesi (tidak dibiarkan semalaman atau selama akhir pekan) untuk menghindari perbedaan waktu.

7.1. Proses upgrade SyncServer

Perintah berikut harus dijalankan dari direktori rilis paket update yang diekstrak.

1. Cari firmware terbaru untuk diekstrak:

   ${ARTIFACTS_ROOT}/gdcloud artifacts tree ${ARTIFACTS_ROOT}/oci/ | grep syncserver | grep -v .sig$
   

   Nama file berisi versi firmware.

   Contoh output:

   │   ├── gdch-syncserver-firmware/syncserver:5.1.2
   

2. Salin hanya nama file dan tetapkan ke variabel ini:

   export SYNCSERVER_VERSION=syncserver:5.1.2
   

3. Ekstrak firmware dari image OCI:

   ${ARTIFACTS_ROOT}/gdcloud artifacts extract ${ARTIFACTS_ROOT}/oci syncserver_firmware --image-name=gdch-syncserver-firmware/${SYNCSERVER_VERSION:?}
   

4. Ekstrak firmware:

   tar -xvzf syncserver_firmware/gdch-syncserver-firmware/syncserver.tar.gz
   

   Anda harus melihat satu file *.dat dan satu file *updater.zip di direktori output.

5. Ikuti runbook NTP-P0002 - Access SyncServer UI.

   1. Buka Help -> About -> Software Version. Jika software yang diinstal sama dengan atau lebih baru dari firmware yang disediakan, firmware tidak perlu diupdate dan langkah-langkah berikutnya dapat dilewati.

   2. Buka Admin -> Upgrade di UI SyncServer. Upload syncserver_s650_license.dat di Authorization File dan syncserver_s650_updater.zip di Upgrade File. Kemudian, klik instal.

   

Mengupgrade org tenant global

Mengupgrade org tenant global pada tingkat tinggi mencakup langkah-langkah berikut:

1. Upgrade organisasi tenant di semua zona. Setiap zona diupgrade satu per satu.

   Penting: Mulai upgrade dengan zona utama StorageGrid, lalu ulangi untuk semua zona lain dalam deployment. Urutan ini diperlukan agar penyimpanan objek berfungsi dengan baik.

   Periksa apakah zona saat ini adalah zona primer. Perintah berikut menampilkan "true" di zona utama dan tidak menampilkan apa pun di zona non-utama.

   kubectl get ObjectStorageAdminNode -o jsonpath='{.items[*].status.isPrimary}' --kubeconfig=ROOT_ADMIN_KUBECONFIG; echo
   

2. Mengupgrade resource organisasi tenant global.

Pemeriksaan sebelum upgrade

Upgrade zona satu per satu. Sebelum memulai upgrade org di satu zona, hubungkan ke semua zona lainnya dan jalankan perintah berikut untuk memastikan perintah menampilkan status siap di semua zona. Jika ada zona yang melaporkan bahwa zona tersebut belum siap, jangan lanjutkan upgrade. Periksa org di zona tersebut untuk mendiagnosis masalah.

ORG_NAME=ORG_NAME

[[ $(kubectl --kubeconfig=ROOT_ADMIN_KUBECONFIG get org ${ORG_NAME} -n gpc-system -ojsonpath='{.status.conditions[?(@.type=="Ready")].status}') == 'True' ]] && echo ready || echo not ready

Pastikan semua cluster dalam status berjalan dan semua node pool dalam status siap. Jika belum, perbaiki terlebih dahulu sebelum memulai upgrade.

ORG_NAME=ORG_NAME
kubectl get nodepools -n ${ORG_NAME} --kubeconfig ROOT_ADMIN_KUBECONFIG -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status'
# Example output
# NAMESPACE   NAME                                        READY
# org1        admin-control-plane-node-pool               True
# org1        data-plane-pool-o2-standard1-96-gdc-metal   True

kubectl get cluster -n mks-system --kubeconfig ORG_MGMT_API_KUBECONFIG
# Example output
# NAME                    STATE     K8S VERSION
# g-org1-perimeter        Running   1.30.6-gke.300
# g-org1-shared-service   Running   1.30.6-gke.300

kubectl get nodepool -A --kubeconfig ORG_INFRA_KUBECONFIG -o custom-columns='NAMESPACE:.metadata.namespace,NAME:.metadata.name,READY:.status.conditions[?(@.type=="Ready")].status'
# Example output
# NAMESPACE                       NAME                                                     READY
# g-org1-perimeter-cluster        control-plane-node-pool                                  True
# g-org1-perimeter-cluster        perimeter-admin-node-pool                                True
# g-org1-perimeter-cluster        perimeter-data-node-pool                                 True
# g-org1-shared-service-cluster   control-plane-node-pool                                  True
# g-org1-shared-service-cluster   dbs-billing-system-billing-dbcluster-n2-standard-4-gdc   True
# g-org1-shared-service-cluster   shared-service-default-worker                            True

1. Mengupgrade org tenant

Langkah ini mengupgrade versi Kubernetes, add-on, komponen yang dapat dioperasikan di cluster bidang pengelolaan dalam organisasi tenant - cluster admin org, sistem, dan layanan.

Durasi keseluruhan upgrade bergantung pada jumlah tahap dalam upgrade. Upgrade otomatis org tenant dapat mengganggu dan memerlukan masa pemeliharaan.

Catatan: Mengupgrade org tenant ke versi minor yang lebih rendah dari org root tidak didukung.

1.1. Persiapan

Untuk mengonfigurasi masa pemeliharaan, ikuti Mengonfigurasi masa pemeliharaan untuk upgrade org Tenant.

Petunjuk untuk memulai upgrade org tenant diberikan untuk penggunaan perintah CLI kubectl atau perintah infrastruktur sebagai kode (IaC). Untuk menggunakan perintah IaC, konfigurasi IaC terlebih dahulu:

• Penyiapan infrastruktur sebagai kode.

• Konfigurasi infrastruktur sebagai kode.

  Untuk menggunakan nomos guna memverifikasi status seperti yang dirujuk dalam langkah-langkah berbasis IaC sebagai opsi, Anda harus menginstal alat command line nomos. Untuk mendapatkan petunjuk penginstalan dan penggunaan nomos, buka https://cloud.google.com/anthos-config-management/docs/how-to/nomos-command dari komputer yang memiliki akses internet.

Penting: Jika IaC diaktifkan, Anda harus melakukan upgrade menggunakan IaC.

IaC

Tetapkan clusterrolebinding sebelum memulai upgrade org tenant menggunakan IAC

1. Buka direktori iac/infrastructure/zonal/zones/ZONE_NAME/{ORG}.
2. Masuk ke direktori IO yang sudah dibuat. Jika direktori tidak ada, buat direktori baru.

3. Tambahkan file YAML untuk menetapkan peran cluster io-organization-admin ke IO. Contoh:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: iac-binding-$USER-io-organization-admin
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: io-organization-admin
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: User
     name: USER_EMAIL
   

4. Perbarui kustomatization.yaml untuk menyertakan file baru yang dibuat. Jika kustomatization.yaml tidak ada, buat file baru:

   kind: Kustomization
   metadata:
     name: org-1-admin-kustomization
   resources:
   - FILE_NAME.yaml
   

5. Kirim perubahan di IAC

kubectl

Tetapkan clusterrolebinding sebelum memulai upgrade org tenant menggunakan kubectl

1. Tetapkan KUBECONFIG ke file kubeconfig untuk cluster admin root.

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG`
   

2. Buat ClusterRoleBindings yang diperlukan:

   kubectl create clusterrolebinding io-organization-admin --clusterrole=organization-admin --user=USER_EMAIL`
   

3. Sebelum Anda menyelesaikan upgrade dari versi Distributed Cloud sebelumnya ke 1.13.x +, ikuti petunjuk dalam runbook BIL-R0014 untuk membuat invoice secara manual untuk biaya bulan ini dari awal bulan ini hingga awal tanggal hari ini. Anda akan kehilangan data biaya yang dibuat selama proses upgrade organisasi Distributed Cloud.

1.2. Mulai upgrade

Upgrade org tenant juga dipicu melalui IaC dengan memperbarui kolom versi di objek OrganizationZonalConfig yang sesuai dari org di zona. Berikut detailnya:

1. Perbarui versi di file YAML OrganizationZonalConfig.

   ORG_NAME=ORG_NAME
   ZONE=$(kubectl --kubeconfig ROOT_ADMIN_KUBECONFIG get controlplane cp -n mz-system -ojsonpath='{.spec.zone}')
   sed -i 's/version: .*$/version: VERSION/' IAC_REPO_PATH/iac/infrastructure/global/orgs/root/${ORG_NAME}-${ZONE}.yaml
   

2. Siapkan dan commit perubahan file.

   git add "IAC_REPO_PATH/iac/infrastructure"
   git commit
   

3. Buat permintaan penggabungan.

   git checkout -b ${USERNAME1}-branch
   git -c http.sslVerify=false push -o merge_request.create origin ${USERNAME1}-branch
   

Jika upgrade dimulai, objek OrganizationUpgrade akan dibuat. Pastikan objek OrganizationUpgrade dibuat di cluster admin root di zona.

kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml --kubeconfig ROOT_ADMIN_KUBECONFIG

Jika OrganizationUpgrade tidak ditemukan, ikuti runbook IAC-R0001 untuk memecahkan masalah.

1.3. Upgrade

1. Upgrade dilakukan saat memiliki timeWindow yang berada dalam masa pemeliharaan yang ditentukan oleh pengguna administrator, yang juga disebut PA. Melihat timeWindow terjadwal:

   kubectl -n gpc-system get organizationupgrade ORG_NAME -o yaml
   

   Berikut adalah respons umum terhadap perintah sebelumnya:

   apiVersion: upgrade.private.gdc.goog/v1alpha1
   kind: OrganizationUpgrade
   metadata:
     creationTimestamp: "2022-08-22T01:09:03Z"
     generation: 1
     name: org-1
     namespace: gpc-system
     ownerReferences:
     - apiVersion: resourcemanager.gdc.goog/v1alpha1
       blockOwnerDeletion: true
       controller: true
       kind: Organization
       name: org-1
       uid: 6998cfc1-bee4-4f6d-baf2-9c0a90ef93bb
     resourceVersion: "1214182"
     uid: 1affc1df-b9ac-4343-8e61-18736781a990
   spec:
     currentVersion: 1.8.0-gdch.476
     organizationRef:
       name: org-1
     targetVersion: 1.8.1-gdch.0
     timeWindow:
       end: "2022-08-28T04:00:00Z"
       start: "2022-08-28T00:00:00Z"
   

   Dalam contoh sebelumnya, jadwal upgrade ke 1.8.1-gdch.0 adalah antara "2022-08-28T00:00:00Z" dan "2022-08-28T04:00:00Z".

   Saat upgrade dimulai, objek OrganizationUpgrade dibuat, yang ditampilkan sebagai kind: OrganizationUpgrade dalam contoh output sebelumnya.

   kind: OrganizationUpgrade
   

2. Pantau status keseluruhan upgrade menggunakan objek upgrade yang sesuai, dengan menambahkan perintah di langkah 1 dengan -w. Misalnya, untuk terus-menerus mengkueri ORG_NAME untuk mengetahui status upgrade, jalankan perintah berikut:

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   kubectl get -n gpc-system organizationupgrade ORG_NAME -o yaml -w
   

3. Tahapan upgrade dan statusnya dapat dilihat menggunakan cara berikut:

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   kubectl get -n gpc-system organizationupgrade ORG_NAME -o jsonpath='{.status.conditions}' | \
   jq -r '["Stage", "Status", "Reason", "Message"], ["---", "---", "---", "---"], (.[] | [.type, .status, .reason, .message]) | @tsv' | column -ts $'\t'
   

   Tahap Succeeded mengacu pada status upgrade secara keseluruhan. Tahap Expired digunakan untuk menunjukkan bahwa upgrade telah melewati waktu yang dijadwalkan semula. Semua tahap lainnya mengacu pada langkah-langkah upgrade yang sedang berlangsung. Status True mengacu pada langkah-langkah yang telah selesai dan Status Unknown mengacu pada langkah upgrade saat ini.

   Jika pemeriksaan awal gagal dan Anda yakin bahwa kegagalan pemeriksaan awal ini adalah positif palsu, ganti dan lewati opsi pemeriksaan awal:

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   kubectl annotate -n gpc-system organization ORG_NAME \
       upgrade.private.gdc.goog/skip-preflight-check=ok
   

   Jika pemeriksaan pasca-penerbangan gagal, dan Anda yakin bahwa kegagalan tersebut adalah positif palsu, ganti dan lewati pemeriksaan pasca-penerbangan:

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   kubectl annotate -n gpc-system organization ORG_NAME \
       upgrade.private.gdc.goog/skip-postflight-check=ok
   

4. Jika IAC digunakan untuk mengupgrade organisasi tenant dan status organizationupgrade menunjukkan Berhasil dan Organization untuk organisasi tenant tidak dalam status Siap, terapkan solusi sementara berikut.

   Tambahkan anotasi ini: configmanagement.gke.io/managed: disabled menggunakan IAC ke organisasi. Status Monitor Organization dalam status Siap.

5. Upgrade organisasi kini akan dilanjutkan ke tahap berikutnya, dan status untuk layanan atau node akan selesai:

   Last Transition Time: 2024-08-27T22:44:09Z
     Message:             observed the following reason: [JobRunning]
     Observed Generation: 614
     Reason:              Complete
     Status:              True
     Type:                service/Node
   

   Diperlukan waktu 15 menit agar upgrade organisasi dapat dilanjutkan.

1.4. Pemeriksaan pasca-upgrade

1. Periksa objek Organization untuk organisasi. Kondisi READY harus ditampilkan sebagai True.

   kubectl -n gpc-system get organization ORG_NAME
   

   Contoh output:

   NAME   READY
   org-1  True
   

2. Periksa Organization.Status.Version. Harus menampilkan string yang sama persis dengan versi target:

   kubectl -n gpc-system get organization ORG_NAME -o jsonpath='{.status.version}{"\n"}'
   

   Contoh output:

   1.13.3-gdch.5548
   

   Penting: Jika Anda memicu update di luar jadwal dengan menggunakan anotasi untuk mengabaikan masa pemeliharaan, Anda harus mengembalikannya untuk menggunakan masa waktu terjadwal.

   Mengembalikan anotasi untuk mengabaikan masa pemeliharaan:

   kubectl annotate organization ORG_NAME -n=gpc-system  \
       "upgrade.private.gdc.goog/ignore-maintenance-window-" \
       --kubeconfig=ROOT_ADMIN_KUBECONFIG
   

3. Periksa kegagalan subkomponen di org tenant yang diupgrade :

   1. Periksa subkomponen yang menampilkan status ReconciliationError atau Reconciling. Arahkan kubeconfig ke ORG_MGMT_API_KUBECONFIG:

      export KUBECONFIG=ORG_MGMT_API_KUBECONFIG
      
      echo "Subcomponents with failures"
      kubectl get subcomponent -A -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "ReconciliationError") |  "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'
      echo "Subcomponents still reconciling"
      kubectl get subcomponent -A -o json | jq -r '.items[] |  select(.status.conditions[]?.reason == "Reconciling") | select( "\(.status)" | contains("PreinstallPending") | not) | "Sub-Component: \(.metadata.name) - \(.status.conditions[]?.message)"'
      

   2. Jika terjadi error, periksa catatan rilis dan masalah umum untuk mengetahui solusinya. Jika tidak ada, hubungi Distributed Cloud untuk mendapatkan bantuan pemecahan masalah.

4. Jika pemeriksaan pra-penerbangan atau pemeriksaan pasca-penerbangan dilewati, hapus anotasi setelah upgrade selesai:

   Contoh:

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   kubectl annotate -n gpc-system organization ORG_NAME \
       upgrade.private.gdc.goog/skip-preflight-check-
   

   export KUBECONFIG=ROOT_ADMIN_KUBECONFIG
   kubectl annotate -n gpc-system organization ORG_NAME \
       upgrade.private.gdc.goog/skip-postflight-check-
   

1.5. Mulai upgrade yang tidak terjadwal

Penting: Bagian ini membahas cara memulai upgrade di luar periode pemeliharaan terjadwal. Pastikan bagian Mulai upgrade terjadwal telah diselesaikan sebelum melanjutkan. Langkah-langkah untuk memulihkan jangka waktu jendela pemeliharaan setelah Anda selesai juga disediakan di sini.

Memicu upgrade tenant-org secara instan di luar maintenanceWindow jika Anda memiliki kebutuhan mendesak seperti persyaratan patch keamanan mendesak. Upgrade ini hanya diperlukan di organisasi tenant, karena organisasi root sudah memicu upgrade secara instan.

Jalankan perintah ini menggunakan kubeconfig root-admin. Resource kustom organisasi yang perlu Anda beri anotasi hanya ada di cluster root-admin. Anda tidak menjadwalkan periode waktu untuk proses ini.

1. Patch org spec/version untuk org tenant:

   export VERSION=$(kubectl get releasemetadata -ojson | jq -r '.items[] | select(.metadata.name | contains("1.13.3")) | .metadata.name')
   echo $VERSION
   
   # Example output
   # 1.13.3-gdch.5548
   
   kubectl patch -n gpc-system organization ORG_NAME --type='json' \
     -p='[{"op":"replace","path":"/spec/version","value":"'${VERSION}'"}]' \
       --kubeconfig=ROOT_ADMIN_KUBECONFIG
   

2. Mulai tenant-org upgrade secara instan dengan menerapkan anotasi ignore-maintenance-window dan memulai ulang organizationupgrade.

   Catatan: Jika upgrade menampilkan error, terapkan perintah yang sama lebih dari sekali.

3. Pantau status upgrade:

   # kubectl -n gpc-system get organizationupgrade org-1 -o yaml
   

4. Lakukan Pemeriksaan pasca-upgrade.

5. Setelah upgrade mendesak selesai, kembali gunakan periode waktu terjadwal:

   kubectl annotate organization ORG_NAME -n=gpc-system  \
         "upgrade.private.gdc.goog/ignore-maintenance-window-" \
         --kubeconfig=ROOT_ADMIN_KUBECONFIG
   

   Catatan: Jika upgrade DNS gagal, lihat DNS R0006 untuk memecahkan masalah.

2. Upgrade DNS

2.1 Membuat zona penerusan

1. Mengekspor kubeconfig untuk cluster admin root:

   export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
   

2. Konfigurasi OCIT_DOMAIN menggunakan zona penerusan. Ganti OCIT_DOMAIN dengan nama domain OCIT Anda dan endpoint dengan alamat IP OC DNS:

   kubectl apply -f - <<EOF
   apiVersion: network.private.gdc.goog/v1alpha1
   kind: DNSZone
   metadata:
     namespace: dns-system
     name: ocit-domain
   spec:
     domainName: OCIT_DOMAIN
     forwardingConfig:
       # Set to OC DNS IPs (the AD domain controllers)
       endpoints:
         - 192.0.2.0
         - 192.0.2.1
       replicateToTenantOrg: true
   EOF
   

   Outputnya akan terlihat seperti contoh ini:

   dnszone.network.private.gdc.goog/ocit-domain created
   

3. Jika perubahan tidak diterapkan, mulai ulang deployment:

   kubectl rollout restart deployment -n dns-system gpc-coredns-forwarder
   

   Perubahan DNS ini disebarkan ke semua cluster di GDC.

4. Dengan kubeconfig admin root, validasi bahwa resolusi domain OCIT berfungsi sebagaimana mestinya:

   NAMESERVER=$(kubectl -n dns-system get service gpc-coredns-forwarder-udp | \
     awk '/[0-9]\./ {print $4}')
   dig +short @${NAMESERVER} fs.OCIT_DOMAIN
   

5. Ekspor kubeconfig untuk cluster admin org:

   export KUBECONFIG=/root/release/org-admin/org-admin-kubeconfig
   

6. Terapkan kubeconfig admin org, dan validasi bahwa resolusi domain OCIT berfungsi sebagaimana mestinya:

   NAMESERVER=$(kubectl -n dns-system get service gpc-coredns-infra-forwarder | \
     awk '/[0-9]\./ {print $4}')
   dig +short @${NAMESERVER} fs.OCIT_DOMAIN
   

2.2 Mengaktifkan resolver rekursif

Aktifkan resolver rekursif di cluster admin org hanya untuk organisasi v1, dengan mengikuti langkah-langkah dalam runbook DNS-R0027.

Menyelesaikan upgrade tenant org di semua zona

Setelah upgrade selesai di satu zona, sebaiknya periksa apakah zona tersebut masih berfungsi dengan baik sebelum melanjutkan upgrade zona berikutnya.

Ulangi Langkah 1 hingga 2 untuk organisasi tenant di zona lainnya. Setelah semua zona mengupgrade org tenantnya, lanjutkan ke langkah berikutnya.

3. Mengupgrade resource global

Resource global harus berada di versi terendah dari semua zona. Mulai proses upgrade resource global dengan menghubungkan ke zona anchor dan menjalankan perintah berikut.

# Annotate appropriate versions for all the operable components.
ORG_NAME=ORG_NAME
MAP=$(kubectl get kubeapiserver ${ORG_NAME}-admin -n ${ORG_NAME} -ojsonpath='{.metadata.annotations}' --kubeconfig ROOT_ADMIN_KUBECONFIG | jq -r 'to_entries | map("\(.key) \(.value)") | .[] | select(startswith("lcm.private.gdc.goog/oc-version-"))')

# Trigger the global resource upgrade on global org admin.
kubectl annotate kubeapiserver global-org-admin -n global-kube-system --overwrite lcm.private.gdc.goog/paused-remote=false --kubeconfig ORG_MGMT_API_KUBECONFIG
kubectl patch kubeapiserver global-org-admin -n global-kube-system -p='{"spec":{"deploymentPolicy":"AllowAll"}}' --type=merge --kubeconfig ORG_MGMT_API_KUBECONFIG

Proses ini mungkin membutuhkan waktu beberapa menit. Verifikasi penyelesaian upgrade resource global dengan menjalankan perintah berikut. Tidak ada kegagalan yang akan dilaporkan dari perintah.

Penting: Verifikasi hanya boleh dilakukan di zona penanda. Zona lainnya akan dijeda dan statusnya mungkin tidak diperbarui.

# Verify that Components are all successfully rolled out on global org admin.
echo "${MAP}" | while read KV; do
   SPLIT=(${KV}); VALUE=${SPLIT[1]}; OC=$(echo ${VALUE} | cut -d- -f1)
   [[ -n ${OC} ]] || continue
   ROLLOUT=$(kubectl get componentrollout ${OC} -n global-kube-system -o json --ignore-not-found --kubeconfig ORG_MGMT_API_KUBECONFIG)
   [[ -n ${ROLLOUT} ]] || continue
   if [[ $(echo ${ROLLOUT} | jq -r '.spec.componentRef.name') != ${VALUE} ]] ; then
      echo "${OC} rollout trigger failed"; continue
   fi
   if [[ $(echo ${ROLLOUT} | jq -r '.status.allSubcomponentsReady') != 'true' ]] ; then
      echo "${OC} rollout completion failed. Use 'kubectl describe componentrollout ${OC} -n global-kube-system --kubeconfig ORG_MGMT_API_KUBECONFIG' to check for error messages."
   fi
done && echo "Global component rollout check finished."

Catatan: Subkomponen dengan nama back-lancer-agent-user-cp di server API pengelolaan dalam status ReconciliationError harus dihapus secara manual agar pencadangan di cluster pengguna atau bersama dapat diaktifkan.

4. Mengupgrade Tenable SC

1. Jalankan GDCH doctor untuk menentukan apakah upgrade diperlukan -

     gdcloud system doctor diagnose instance --include-ocs=vuln --root-admin-kubeconfig=${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}
   

2. Jika validator tenable_sc_upgrade_readiness gagal, gambar perlu diupgrade. Ikuti langkah-langkah berikut untuk mengupgrade Tenable SC di org layanan OI -

   1. Dapatkan nama virtual machine:

       VIRTUAL_MACHINE_NAME=$(kubectl --kubeconfig ${OI_SERVICES_ORG_INFRA_KUBECONFIG:?} get virtualmachine -n tenablesc-system -o custom-columns=NAME:.metadata.name | sort -r -k 1 | head -1)
      

   2. Tandai runningState mesin virtual sebagai Stopped:

       kubectl --kubeconfig ${OI_SERVICES_ORG_MGMT_KUBECONFIG:?} patch virtualmachines.virtualmachine.gdc.goog ${VIRTUAL_MACHINE_NAME:?} -n tenablesc-system --type merge --patch '{"spec":{"runningState":"Stopped"}}'
      

   3. Uninstal diagram Helm yang ada untuk VM:

       VIRTUAL_MACHINE_NAME=$(kubectl --kubeconfig ${OI_SERVICES_ORG_INFRA_KUBECONFIG:?} get virtualmachine -n tenablesc-system -o custom-columns=NAME:.metadata.name | sort -r -k 1 | head -1)
       kubectl --kubeconfig ${OI_SERVICES_ORG_MGMT_KUBECONFIG:?} patch virtualmachines.virtualmachine.gdc.goog ${VIRTUAL_MACHINE_NAME:?} -n tenablesc-system --type merge --patch '{"spec":{"runningState":"Stopped"}}'
       helm uninstall tenablesc-vms -n tenablesc-system --kubeconfig ${ORG_MGMT_KUBECONFIG:?}
      

   4. Lakukan penyiapan baru Tenable SC dengan mengikuti Menginstal Tenable.SC

Pembersihan pasca-upgrade

Hapus resource ClusterRoleBinding yang dibuat di bagian Identity and Access Management.

Mengonfigurasi masa pemeliharaan untuk upgrade org Tenant

Untuk mengupgrade organisasi (org) tenant, pastikan Anda diberi peran pelihat dan admin yang benar seperti yang dijelaskan di halaman Deskripsi peran standar dan Definisi peran untuk project untuk login ke antarmuka command line (CLI) kubectl dan antarmuka pengguna (UI) Konsol. Jika Anda tidak memilikinya, gunakan petunjuk di halaman Memberi akses ke resource project untuk memberi akses atau meminta agar akses diberikan kepada Anda.

Untuk mengonfigurasi masa pemeliharaan, Anda harus memiliki peran yang diperlukan. Pastikan Anda memiliki peran bawaan berikut yang ditetapkan kepada Anda:

• Admin Upgrade Organisasi
• Pelihat Upgrade Organisasi Catatan: Mengupgrade organisasi tenant ke versi minor yang lebih rendah dari organisasi root tidak didukung.

Secara default, ada satu MaintenanceWindow untuk upgrade minor dan satu MaintenanceWindow untuk upgrade patch. Upgrade kecil meningkatkan fungsi atau membuat perubahan dari revisi sebelumnya, yang merupakan upgrade paket—misalnya, untuk memperbaiki bug. Upgrade patch mengatasi masalah atau kerentanan tertentu. Konfigurasi patch default MaintenanceWindow untuk memulai upgrade patch sesuai dengan jadwal yang ditentukan.

Untuk mengonfigurasi masa pemeliharaan, gunakan perintah CLI dan kubectl untuk mengubah kolom RRULE dan TimeWindow dari resource MaintenanceWindow. Tindakan ini akan menjadwalkan upgrade Anda. Untuk mengetahui informasi tentang RRULE, buka https://pkg.go.dev/github.com/teambition/rrule-go.

Untuk menggunakan perintah CLI kubectl, klik tab kubectl. Untuk melihat petunjuk berbasis UI, klik tab Konsol.

Konsol

1. Login ke UI Organisasi.

2. Edit jadwal masa pemeliharaan. Buka tab Pemeliharaan, lalu klik Edit.

   Penting: Jika Anda adalah pengguna administratif, Anda memerlukan peran Admin Upgrade Organisasi untuk mengedit MaintenanceWindow dan peran Pelihat Upgrade Organisasi untuk melihat upgrade terjadwal:

   

   Gambar 1. Masa Pemeliharaan

3. Layar Edit masa pemeliharaan akan terbuka. Gunakan jendela untuk mengonfigurasi ulang interval waktu Patch dan Minor:

   

   Gambar 2. Mengonfigurasi ulang patch dan update minor

   Catatan: Kolom Pengulangan untuk Versi Minor menunjukkan instance pertama, kedua, ketiga, keempat, atau terakhir dari Hari yang ditentukan. Jika suatu bulan hanya memiliki empat kemunculan hari tertentu, kemunculan terakhir dan keempat setara.

4. Tentukan atau edit Versi patch, Waktu mulai, dan Durasi, serta hari dalam seminggu.

   Edit Waktu mulai, Durasi, Pengulangan, dan Hari Versi kecil.

   
   

   Gambar 3. Menyimpan konfigurasi ulang

5. Klik Simpan untuk menerapkan perubahan.

6. Jika perubahan tersimpan memengaruhi pengulangan, misalnya: jika Anda menerapkan perubahan pada hari dalam seminggu atau pada bulan, Anda akan melihat dialog. Untuk mengonfirmasi perubahan, klik LANJUTKAN.
   

   

   Gambar 4. Klik Lanjutkan

7. Contoh berikut menunjukkan upgrade terjadwal yang diperbarui, berdasarkan perubahan konfigurasi Anda. Perhatikan link Lewati di samping setiap status tertunda. Gunakan opsi ini untuk melewati upgrade tertunda terjadwal.

   
   Gambar 5. Tampilan upgrade terjadwal, dengan opsi lewati untuk setiap
   

kubectl

1. Login ke kubectl CLI. Temukan petunjuk ini di tab CLI. Pastikan Anda memiliki akses yang benar ke cluster admin org sebelum melanjutkan.

2. Anda dapat mengubah tiga kolom di MaintenanceWindow untuk mengonfigurasi timeWindow tempat upgrade tenant-org terjadi. Perintah berikut menunjukkan modifikasi pada periode pemeliharaan upgrade patch. Modifikasi upgrade minor serupa.

   # 1. The first change is to the RRULE
   # For patch-upgrades to happen, for example, every Thursday instead of Sunday:
   kubectl patch -n gpc-system maintenancewindow patch-upgrade \
     --type='json' \
     -p='[{"op":"replace","path":"/spec/recurrence","value":"FREQ=WEEKLY;BYDAY=TH"}]'
   
   # 2. Modify the start time of the upgrade in UTC.
   export S_TIME = 2022-04-03T04:00:00Z
   kubectl patch -n gpc-system maintenancewindow patch-upgrade \
     --type='json' \
     -p='[{"op":"replace","path":"/spec/timeWindow/start","value":"'${S_TIME}'"}]'
   
   # 3. Modify the end time of the upgrade in UTC.
   export E_TIME = 2022-04-03T04:00:00Z
   kubectl patch -n gpc-system maintenancewindow patch-upgrade \
     --type='json' \
     -p='[{"op":"replace","path":"/spec/timeWindow/end","value":"'${E_TIME}'"}]'
   

   Waktu mulai dan waktu berakhir, /spec/timeWindow/start dan /spec/timeWindow/end, masing-masing harus memiliki tanggal/bulan/tahun yang telah terjadi di masa lalu. Jangka waktu dihitung berdasarkan nilai yang Anda masukkan.

Alokasikan setidaknya durasi minimum seperti yang ditampilkan untuk setiap jenis upgrade. Anda dapat mengalokasikan durasi yang lebih lama seperti yang dinyatakan dalam rekomendasi berikut:

• Upgrade kecil: Memerlukan waktu minimal 12 jam dalam jangka waktu 32 hari.

• Upgrade patch: Memerlukan waktu minimal 48 jam dalam jangka waktu 32 hari, dengan 1 blok waktu atau lebih. Meskipun konsol menampilkan spesifikasi periode minimum 4 jam, Google menyarankan agar Anda mengalokasikan setidaknya 6 jam untuk setiap blok waktu.

  Penting: Upgrade patch Anda mungkin tidak memerlukan waktu 6 jam penuh, tetapi Google merekomendasikan alokasi waktu ini untuk memperhitungkan proses patch yang panjang.

Upgrade Manual Operations Suite Infrastructure Core

Proses upgrade ini hanya berlaku untuk upgrade dari versi 1.13.x ke 1.14.3.

Pastikan semua akun lokal dan domain terkelola diaktifkan dengan sandi yang belum habis masa berlakunya. Akun yang tidak dalam kondisi baik dapat menyebabkan error dalam proses ini.

Melakukan Checkpoint VM dan Pencadangan Direktori

1. Lakukan checkpoint VM.

   1. Di host BM01, buka konsol PS sebagai Administrator.

   2. Jalankan perintah berikut untuk setiap host Hyper-V di cluster.

      $servername = "<*hyperv-server-name*>"
      Get-VM -CimSession $servername  | ForEach-Object {
      $myargs = @{
      VMName = $_.Name
      SnapshotName = "Checkpoint_$($_.Name)_$(Get-Date -Format 'yyyyMMddHHmmss')"
      ComputerName = $servername
      }
      Checkpoint-VM @myargs
      }
      

      Biarkan jendela PowerShell tetap terbuka untuk langkah berikutnya

2. Mengaktifkan jalur file panjang

     $path = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
     Set-ItemProperty -Path $path -Name 'LongPathsEnabled' -Value 1
   

3. Cadangkan drive H:\operations_center. (Tindakan ini mendukung mengembalikan upgrade.)

     Rename-Item -Path H:\operations_center -NewName operations_center_backup
   

4. Cadangkan direktori konfigurasi di CONFIG1. (Backup ini memberikan referensi saat membuat konfigurasi config.ps1 baru.)

   1. Di host BM01, gunakan Remote Desktop Protocol (RDP) untuk terhubung ke alamat IP VM CONFIG1 dan login dengan akun administrator sistem. Contoh: mstsc /v 192.168.100.99

   2. Buka konsol PS dengan Run as Administrator.

      • Buat folder cadangan

      mkdir c:\config1_backup
      

      • Mencadangkan C:\dsc

      Move-Item -Path "C:\dsc\" -Destination "C:\config1_backup"
      

      • Mencadangkan C:\config

      Move-Item -Path "C:\config\" -Destination "C:\config1_backup"
      

      • Mencadangkan C:\operations_center

      Move-Item -Path "C:\release\operations_center\" -Destination "C:\config1_backup"
      

      • Memastikan jalur file panjang diaktifkan

      $path = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
      Set-ItemProperty -Path $path -Name 'LongPathsEnabled' -Value 1
      

Memuat software pihak ketiga

Lakukan tugas di software pihak ketiga.

Mengupgrade Virtual Machine yang ada

1. Dapatkan direktori Penginstalan.

   1. Download paket komponen OIC dengan mengikuti petunjuk di bagian Download files.

      Catatan: Jika lingkungan Anda terisolasi, Anda harus menyalin file *.tar.gz ke drive USB untuk ditransfer.

   2. Di host BM01, ekstrak direktori operations_center dari prod_IT_component_bundle.tar.gz yang didownload.

      Catatan: Menjalankan tar.exe di Windows akan mengekstrak ke direktori kerja saat ini. Salin file ke drive H sebelum mengekstrak.

      Set-Location H:
      tar -zxvf prod_IT_component_bundle.tar.gz
      

      Mengekstrak file TAR akan membuat folder release di root H:

   3. Pindahkan operations_center ke root H:

      Move-Item -Path H:\release\operations_center -Destination H:\
      

2. Perbarui config.ps1 dengan data khusus situs

   File konfigurasi config.ps1 menyediakan semua informasi yang diperlukan untuk membangun dan mengonfigurasi lingkungan Infrastruktur Operations Suite (OI). Untuk memperbarui file konfigurasi, Anda harus mengumpulkan semua informasi berikut. Cadangan config.ps1 yang ada adalah referensi yang baik untuk melindungi penimpaan setelan yang ada secara tidak sengaja. Penting: Jangan lanjutkan hingga config.ps1selesai dan benar.

   • Output konfigurasi jaringan alat occonfigtool, terutama file ocinfo.common.opscenter.local.txt. Nama jaringan, misalnya, OCCORE-SERVERS yang dirujuk dalam langkah-langkah berikut merujuk pada kolom Name dalam dokumen tersebut.
   • Nama domain dan alamat IP server DNS setiap sel GDC yang dikelola OI ini. Data ini tersedia di output Kuesioner Penerimaan Pelanggan (CIQ).

   Lakukan semua perubahan pada host BM01 sebagai Administrator.

3. Salin kode contoh konfigurasi yang benar untuk jenis deployment:

   1. Salin H:\operations_center\dsc\config.example.ps1 ke H:\operations_center\config\config.ps1.

4. Dengan menggunakan VSCode atau Powershell ISE, validasi dan perbarui nilai dalam config.ps1.

   1. Jika OIC di-deploy sebagai multi-situs:

      1. Menemukan komentar yang diberi label ### Multi-Site:
      2. Lakukan tindakan yang dijelaskan dalam komentar yang Anda temukan.

   2. Perbarui HardwareVersion kecuali jika default (3.0) sudah benar.

   3. Perbarui PrimarySiteCode kecuali jika default (DC1) sudah benar.

   4. Kode situs digunakan dalam banyak nama. Telusuri dan ganti semua instance DC1 dengan kode situs yang benar. Gunakan penelusuran yang tidak peka huruf besar/kecil. Tinjau setiap perubahan karena beberapa perubahan mungkin tidak diperlukan. Misalnya, jika kode situs adalah AB1, maka nama host DC1-DC1, harus berubah menjadi AB1-DC1, bukan AB1-AB1.

   5. Perbarui DnsDomain jika defaultnya tidak benar. Jika nilai ini diubah, telusuri dan ganti opscenter.local di seluruh file config.ps1. Ada beberapa lokasi tempat nilai default tersebut dikodekan secara permanen.

   6. Perbarui objek di DnsConditionalForwarder dengan informasi khusus situs. Harus ada setidaknya satu objek penerusan. Hapus contoh yang tidak perlu.

      Langkah ini dapat dilakukan di WSL pada CONFIG1 jika CLI gdcloud dan kubectl sudah diinstal.

      Untuk menarik informasi khusus situs dari cluster admin root, gunakan:

      export KUBECONFIG=/root/release/root-admin/root-admin-kubeconfig
      kubectl get -n dns-system service gpc-coredns-external-udp \
                  -o jsonpath='{.status.loadBalancer.ingress[0].ip}{"\n"}'
      

      1. Domain - Nama domain DNS sel GDC, misalnya, dns.delegatedSubdomain di ciq.yaml.

      2. Master - Daftar IP server DNS (biasanya hanya satu). Cari di cellcfg untuk jenis DNSReservation. Jika sel GDC di-deploy, cari namespace dns-system cluster administrasi root untuk EXTERNAL-IP layanan gpc-coredns-external-udp dan FQDN sel bert.sesame.street.

      3. Dalam deployment multi-situs, ada satu objek tabel hash per sel.

   7. Jangan mengubah konten objek Users, Groups, dan GroupPolicy.

   8. Perbarui DNSServers agar berisi 2 alamat IP yang diberikan ke pengontrol domain primer dan sekunder seperti <SITE>-DC1 dan <SITE>-DC2.

   9. Perbarui NTPServers menjadi daftar alamat IP SyncServer dari resource kustom TimeServer root-admin. Anda dapat mengambil kumpulan alamat IP ini menggunakan:

      kubectl get timeserver -A -o json | jq '.items[].address'
      

      Anda harus memformat alamat IP ini dalam NTPServers seperti yang ditunjukkan dalam contoh berikut:

      NtpServers = @(
        '10.251.80.2',
        '10.251.80.3',
        '10.251.80.4',
        '10.251.80.5'
      )
      

   10. Perbarui nilai default SubnetPrefix, yaitu 24, dengan nilai awalan subnet yang diberikan pelanggan untuk subnet OCCORE-SERVERS jika diperlukan.

   11. Perbarui nilai default DefaultGateway dengan gateway default yang disediakan pelanggan untuk subnet OCCORE-SERVERS.

   12. Temukan dan perbarui nilai default WorkstationCider dengan nilai yang diberikan pelanggan untuk subnet OC-WORKSTATIONS dalam notasi CIDR IPv4.

   13. Perbarui nilai WorkstationAllowRemote menjadi $true jika pelanggan memilih untuk mengizinkan akses jarak jauh ke workstation mereka

   14. Temukan dan ganti contoh awalan subnet 172.21.0. dengan awalan subnet OCCORE-SERVERS yang disediakan pelanggan.

   15. Temukan dan ganti contoh awalan subnet 172.21.2. dengan awalan subnet OCCORE-JUMPHOSTS yang disediakan pelanggan.

   16. Temukan dan ganti contoh awalan subnet 172.21.32. dengan awalan subnet OC-WORKSTATIONS yang disediakan pelanggan.

   17. Cari dan ganti contoh pesan harian legalnoticecaption nilai Pref caption dengan teks yang diberikan pelanggan.

   18. Cari dan ganti nilai contoh pesan harian legalnoticetext dari Pref text dengan teks yang disediakan pelanggan.

   19. Validasi setiap objek "node" dan perbarui, jika diperlukan.

       1. NodeName - Pastikan nama host sudah benar. Beberapa nama digunakan di banyak tempat, misalnya, pengendali domain. Jika Anda mengubah nama di sini, periksa apakah nama tersebut perlu diubah di tempat lain dalam konfigurasi.

       2. IPv4Addr - Ini harus berupa alamat IP host. Oktet terakhir biasanya tidak perlu diubah. Beberapa di antaranya mungkin telah diperbarui selama penelusuran dan penggantian jaringan yang dilakukan pada langkah-langkah sebelumnya.

       3. HyperVHost - Nilai ini harus berupa alamat IP server Hyper-V yang menghosting VM ini. Anda bisa mendapatkan alamat IP untuk setiap server BM?? di bagian "Hyper-V Servers" pada konfigurasi. Jangan mengubah penetapan host Hyper-V di kolom ini karena tidak semua host Hyper-V dapat mendukung setiap jenis VM, cukup ubah nama host Hyper-V ke alamat IP yang sesuai.

   20. Validasi detail antarmuka jaringan kedua di semua node dengan Role=jumphost. Gunakan detail subnet OCCORE-JUMPHOSTS untuk antarmuka ini. Periksa:

       1. JumphostIPv4Cidr
       2. JumphostDefaultGateway

   21. Perbarui stanza khusus ADFS di node tempat Role=adfs.

       Peringatan: JANGAN mengedit bagian konfigurasi ADFS apa pun kecuali jika diarahkan. Selama upgrade, konfigurasi ADFS yang ada tetap ada.
       1. Temukan baris Name = 'SplunkTrust' # Must be unique to the farm. Append "Trust"
       2. Ganti tiga kemunculan opscenter.local setelah baris ini dengan domain DNS Anda

   22. Perbarui cakupan DHCP agar sesuai dengan rencana IP pelanggan sesuai kebutuhan. Untuk setiap cakupan, pastikan nilai berikut sudah benar. Nama pada cakupan cocok dengan nama yang digunakan dalam rencana jaringan ocinfo.common.opscenter.local.txt, jadi gunakan yang berikut dalam validasi:

       1. ScopeId
       2. IpStartRange
       3. IpEndRange
       4. Router
       5. SubnetMask

   23. Konfirmasi bahwa nilai cocok dengan nilai dalam config1.ps1 yang dicadangkan

   24. Pastikan untuk menyimpan file.

Persiapan VM CONFIG1

Persiapan CONFIG1 dilakukan di BM01. Semua upgrade lainnya terjadi saat login ke VM CONFIG1.

1. Salin direktori operations_center ke VM CONFIG1

   1. Di host BM01, buka konsol PS sebagai Administrator.

   2. Salin operations_center untuk menyiapkan file yang diperlukan oleh virtual machine (VM) CONFIG1.

      Catatan: Copy-ConfigHostFiles.ps1 tidak digunakan di sini karena lingkungan sudah beroperasi. Penyalinan SMB menghemat waktu penyalinan hingga berjam-jam.

      # Change name to match your config host
      $config = "DC1-CONFIG1"
      # Stage files for CONFIG1 VM
      Copy-Item  -Path H:\operations_center -Destination "\\$config\c$\" -Recurse -Force
      

   3. Menonaktifkan sinkronisasi waktu Hyper-V

      1. Login ke host BM01 sebagai Administrator.

      2. Buka PowerShell di Windows sebagai Administrator dan jalankan perintah berikut:

      Penting: Dalam cuplikan kode berikutnya, ganti <var>config1_vm_name</var> dengan nama VM CONFIG1, misalnya, DC1-CONFIG1.

      # Disabling Hyper-V Time Sync
      Disable-VMIntegrationService -VMName `<SITE>-CONFIG1` -Name 'Time Synchronization'
      

   4. Persiapan dan validasi VM CONFIG1

      1. Dari host BM01, login ke VM CONFIG1 dengan akun -SA Anda. Hubungkan ke alamat IP VM menggunakan Remote Desktop (RDP). Contoh: mstsc /v 192.168.100.99

      2. Buka jendela PowerShell menggunakan menu "Run as different user" untuk dijalankan sebagai pengguna Marvin.

      3. Di jendela PowerShell baru, mulai sesi administratif:

         Start -Verb runas -FilePath powershell.exe
         

         Tutup jendela powershell sebelumnya, biarkan jendela administrator tetap terbuka.

      4. Pastikan jendela PowerShell administratif berjalan sebagai Marvin

         whoami
         

      5. Tata file yang di-stage dari host BM01.

         Move-Item -Path c:\operations_center -Destination c:\release
         C:\release\operations_center\dsc\Initialize-ConfigHostFiles.ps1
         

      6. Validasi bahwa c:\dsc dan c:\config ada.

      7. Menyalin file kredensial dan sertifikat dari Cadangan

         Copy-Item -Path "C:\config1_backup\config\creds\" -Destination "C:\config\creds\" -Recurse
         Copy-Item -Path "C:\config1_backup\config\certs\" -Destination "C:\config\certs\" -Recurse
         

      8. Buat data MECM yang diperlukan untuk mengompilasi MOF

         C:\dsc\Build-MecmFiles.ps1
         

      9. Validasi lingkungan build sudah siap dengan menjalankan Build-Mof.ps1, yang menghasilkan file MOF untuk semua mesin OI.

         C:\dsc\Build-Mof.ps1
         

   5. Isi variabel kredensial

      Variabel ini digunakan selama proses upgrade. Isi sekali di jendela Marvin Powershell yang dibuka sebagai Administrator.

      . 'c:\config\config.ps1'
      
      $da_creds = (Get-Credential -Message "Provide domain admin credentials")
      $sa_creds = (Get-Credential -Message "Provide system admin credentials")
      
      $sa_args = @{
      Credential = $sa_creds
      SetLcm = $true
      RemoveExisting = $true
      CopyModules = $true
      }
      
      $da_args = @{
      Credential = $da_creds
      SetLcm = $true
      RemoveExisting = $true
      CopyModules = $true
      }
      

   6. Pastikan DSC berjalan dan server dapat dijangkau.

      $role = 'domain_controller'
      $ca = 'ca_root'
      $dcs = $config.AllNodes | Where-Object {$_.role -eq $role}
      $non_dcs = $config.AllNodes | Where-Object {$_.role -ne $role -and $_.role -ne $ca -and $_.NodeName -ne "*"}
      
      $dcs | ForEach-Object {
      $session = New-CimSession -ComputerName $_.NodeName -Credential $da_creds
      Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState}
      
      $non_dcs | ForEach-Object {
      Write-Output "Checking $($_.NodeName)"
      $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
      Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState | ft -AutoSize}
      

      Catatan: Beberapa node mungkin menampilkan status Failure atau memunculkan error The Consistency Check or Pull cmdlet is in progress. Hal ini tidak masalah selama node dapat dijangkau.

Memecahkan masalah konektivitas.

1. Jika New-CimSession gagal, verifikasi nilai NodeName sudah benar di config.ps1. Selain itu, pastikan server sedang online dan dapat dijangkau.

   Error akan dimulai dengan Get-CimSession: WinRM cannot process the request.

Mengupgrade Pengontrol Domain

Peringatan: Selama proses upgrade, kebijakan grup dinonaktifkan sehingga menyebabkan workstation kembali ke setelan default. Jika akses workstation hanya jarak jauh, hal ini dapat menyebabkan workstation tidak dapat diakses. Tentukan cara pelanggan mengaktifkan akses jarak jauh di workstation. Jika berasal dari kebijakan grup, pastikan nama kebijakan tidak diawali dengan SITE- atau OIC- karena akan dihapus pada langkah-langkah berikutnya dengan konvensi penamaan tersebut.

1. Saat login ke CONFIG1, upgrade pengontrol domain utama.

   Isi variabel, hapus GPO lama, dan tautkan GPO baru.

   $dc2 = $dcs | Where-Object {$_.NodeName -like "*-DC2"}
   $dc1 = $dcs | Where-Object {$_.NodeName -like "*-DC1"}
   
   Invoke-Command -Computername $dc1.NodeName -Credential $da_creds -ScriptBlock {
   Remove-DscConfigurationDocument -Stage Current,Pending,Previous
   get-gpo -All | Where-Object { $_.DisplayName -like "OIC*" } | Remove-GPO
   get-gpo -All | Where-Object { $_.DisplayName -like "SITE*" -and $_.DisplayName -notlike "*SCCM*" } | Remove-GPO
   Get-Item "C:\config\domain_controller\oic_gpos"| Remove-Item -Recurse -Force
   Get-Item "C:\config\domain_controller\site_gpo*"| Remove-Item -Recurse -Force
   }
   

   Membatalkan tautan objek Kebijakan Grup. Akun tersebut akan ditautkan di akhir proses upgrade.

   $gpolinks = (Get-Content C:\dsc\data\GpoLinkMapping.yaml -Raw).Replace("LinkEnabled: 'Yes'", "LinkEnabled: 'No'")
   $gpolinks | Out-File C:\dsc\data\GpoLinkMapping.yaml -Force
   

   Upgrade pengontrol domain utama.

   .\Update-RemoteHost.ps1 @da_args -ComputerName $DC1.NodeName
   

   Catatan: Error Copy-Item : An item with the specified name already exists. diperkirakan terjadi selama Installing PowerShell modules on host dan aman untuk diabaikan saat pembaruan node.
   Peringatan: Telah ditemukan masalah yang memengaruhi penyalinan file ke DC karena batasan panjang jalur. Jika terjadi error selama Update-RemoteHost seperti a file that already exists on the target destination selama Copying files for the ... role to host, jalankan perintah ini. Jika tidak, lanjutkan ke langkah berikutnya.

   New-PSDrive -Name DC1 -PsProvider FileSystem -Root "\\$($DC1.NodeName)\c$" -Credential $da_creds
   Invoke-Command -ComputerName $DC1.NodeName -Credential $da_creds -Scriptblock {Remove-DscConfigurationDocument -Stage Current,Pending}
   Remove-Item -Path DC1:\config\domain_controller\site_gpos -Recurse -Force
   Remove-Item -Path DC1:\config\domain_controller\site_gpos_source -Recurse -Force
   Copy-Item -Path C:\config\domain_controller\ -Destination DC1:\config\ -Verbose -Force -Recurse
   C:\dsc\Build-Mof.ps1 -Computername $DC1.NodeName
   Start-DscConfiguration -ComputerName $DC1.NodeName -Path 'c:\config\mofs' -Credential $da_creds -Verbose -Wait -Force
   Remove-PsDrive -Name DC1
   

   1. Memvalidasi sinkronisasi waktu dengan SyncServer

   2. Login ke DC1 menggunakan RDP sebagai administrator domain.

      1. Buka jendela Powershell sebagai administrator.

      2. Jalankan perintah berikut untuk memvalidasi konfigurasi waktu.

         w32tm /query /status /verbose
         

   Penting: Pastikan Last Sync Error: adalah 0, dan Source cocok dengan salah satu alamat IP NtpServers yang dikonfigurasi dalam petunjuk Perbarui server NTP.

   1. Jalankan perintah berikut untuk menguji sinkronisasi ulang waktu:

       # Testing time resyncronization
       w32tm /resync
      

       # Desired output
       Sending resync command to local computer
       The command completed successfully.
      

   2. Validasi ulang bahwa konfigurasi waktu sudah benar dan tidak ada error.

      Penting: Pastikan Last Sync Error: adalah 0, dan Time to Last Good Sync Time: diperbarui (seharusnya kurang dari satu menit jika Anda menjalankannya segera setelah menyinkronkan, misalnya).

       w32tm /query /status /verbose
      

      Peringatan: Jika error terdeteksi atau w32tm /resync gagal, HENTIKAN. Lakukan eskalasi ke OI Engineering sebelum melanjutkan karena ada risiko tinggi pemblokiran deployment OI kecuali jika layanan waktu berfungsi sepenuhnya.

2. Upgrade pengontrol domain kedua.

   1. Gunakan jendela PowerShell CONFIG1 yang ada untuk menjalankan skrip berikut.

      .\Update-RemoteHost.ps1 @da_args -ComputerName $dc2.NodeName
      

3. Validasi replikasi Active Directory.

   1. Setelah DC kedua aktif dan beroperasi, jalankan perintah berikut dari salah satu pengontrol domain untuk memvalidasi replikasi Active Directory:

      repadmin /replsummary
      

      Output harus terlihat seperti berikut:

      PS C:\Users\Administrator.OpsCenter> repadmin /replsummary
      Replication Summary Start Time: 2023-11-29 19:16:59
      
      Beginning data collection for replication summary, this may take awhile:
      ......
      
      Source DSA          largest delta    fails/total %%   error
      OC1-DC1                   01m:49s    0 /  5    0
      
      Destination DSA     largest delta    fails/total %%   error
      OC1-DC2                   01m:49s    0 /  5    0
      

Mengupgrade CA-ISSUING1 dan CA-WEB

Penting: Selalu upgrade CA-ISSUING1 sebelum CA-WEB1.

1. Gunakan terminal PowerShell yang ada di CONFIG1 untuk mengupgrade CA-ISSUING1.

     $ca_iss = $config.AllNodes | Where-Object {$_.role -eq "ca_issuing"}
     c:\dsc\Update-RemoteHost.ps1 @sa_args -ComputerName $ca_iss.NodeName
   

2. Gunakan terminal PowerShell yang ada di CONFIG1 untuk mengupgrade CA-WEB.

     $ca_web = $config.AllNodes | Where-Object {$_.role -eq "ca_web"}
     c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $ca_web.NodeName
   

3. Memvalidasi upgrade

     $ca_iss,$ca_web | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   

Upgrade CA-ROOT1

Gunakan terminal PowerShell yang ada di CONFIG1

1. Nyalakan CA-ROOT1.

     $ca_root = $config.AllNodes | Where-Object {$_.role -eq "ca_root"}
     $session = New-CimSession -ComputerName $ca_root.HyperVHost -Credential $sa_creds
     Start-VM -CimSession $session  -Name $ca_root.NodeName
   

2. Perbarui CA-ROOT1.

     $caroot_cred = Get-GeccoCredential -Name "$($ca_root.NodeName)\caadmin" -CredStore "c:\config\creds"
     c:\dsc\Update-RemoteHost.ps1 -Computername $ca_root.NodeName -RemoteHost $ca_root.Ipv4Addr -Credential $caroot_cred
   

   Catatan: Jika terjadi error autentikasi, login ke server CA-ROOT1 sebagai caadmin. Buka PowerShell sebagai administrator. Masukkan winrm qc, lalu tekan enter. Setujui perubahan dengan y. Logout dari CA-ROOT1 dan coba lagi.

3. Jika CA_ROOT1 tidak melakukan reboot setelah skrip sebelumnya, lakukan reboot secara manual.

4. Validasi upgrade.

     $ca_root | ForEach-Object {
     $session = New-CimSession -ComputerName $_.Ipv4Addr -Credential $caroot_cred
     Get-DscConfigurationStatus -CimSession $session}
   

   Penting: Gunakan w32tm untuk memverifikasi bahwa VM disinkronkan ke Host <SITE>-DC1. Jalankan perintah ini di shell administratif sebagai administrator lokal di CA-ROOT.

5. Verifikasi bahwa setelan Peer adalah <SITE>-DC1.<DNSDOMAIN> dan State adalah Active.

   Jangan lanjutkan jika waktu tidak disinkronkan dengan benar.

     w32tm /query /peers
   
     #Peers: 1
   
     Peer: DC1-DC1.domain.local
     State: Active
     Time Remaining: 31.2997107s
     Mode: 3 (Client)
     Stratum: 1 (primary reference - syncd by radio clock)
     PeerPoll Interval: 6 (64s)
     HostPoll Interval: 6 (64s)
   

6. Matikan CA-Root.

     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Stop-VM -CimSession $session  -Name $ca_root.NodeName
   

Mengupgrade ADFS

Gunakan terminal PowerShell yang ada di CONFIG1

1. Upgrade VM ADFS1.

     $role = 'adfs'
     $adfs = $config.AllNodes | Where-Object {$_.role -eq $role}
   
     $adfs | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   
     $adfs | ForEach-Object {
     c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $adfs.NodeName}
   
   1. Validate the upgrade.
   
     $adfs | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   

Upgrade Jumphost.

Gunakan terminal PowerShell yang ada di CONFIG1

1. Buat array Jumphost.

     $role = 'jumphost'
     $jumps = $config.AllNodes | Where-Object {$_.role -eq $role}
   

2. Upgrade Jumphost.

     $jumps | ForEach-Object {
     c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}
   

3. Validasi upgrade.

     $jumps | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   

Mengupgrade Fileserver.

Gunakan terminal PowerShell yang ada di CONFIG1

1. Buat array yang berisi Fileserver.

     $role = 'file'
     $files = $config.AllNodes | Where-Object {$_.role -eq $role}
   

2. Upgrade Server File.

     $files | ForEach-Object {
     c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}
   

3. Validasi upgrade.

     $files | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   

Upgrade server DHCP.

Gunakan terminal PowerShell yang ada di CONFIG1

1. Upgrade DHCP1.

     $role = 'dhcp_primary'
     $dhcp1 = $config.AllNodes | Where-Object {$_.role -eq $role}
     c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $dhcp1.NodeName
   

2. Validasi upgrade.

     $dhcp1 | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   

3. Upgrade DHCP2.

     $role = 'dhcp_failover'
     $dhcp2 = $config.AllNodes | Where-Object {$_.role -eq $role}
     c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $dhcp2.NodeName
   

4. memvalidasi upgrade.

     $dhcp2 | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   

Mengupgrade server Userlock.

Gunakan terminal PowerShell yang ada di CONFIG1

Catatan: Upgrade Userlock akan memerlukan waktu beberapa menit untuk diinstal dan server mungkin perlu di-reboot.

1. Buat array PowerShell yang berisi server Userlock.

     $role = 'userlock_primary'
     $ulock1 = $config.AllNodes | Where-Object {$_.role -eq $role}
     $role = 'userlock_backup'
     $ulock2 = $config.AllNodes | Where-Object {$_.role -eq $role}
   

2. Hapus file penanda dari penyiapan sebelumnya.

     Invoke-Command -ComputerName $ulock1.NodeName -Credential $sa_creds -Scriptblock { Remove-item "c:\config\userlock_primary\ServiceImpersonation.log" }
     Invoke-Command -ComputerName $ulock2.NodeName -Credential $sa_creds -Scriptblock { Remove-item "c:\config\userlock_backup\ServiceImpersonation.log" }
   

3. Mengupgrade server Userlock utama.

     c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $ulock1.NodeName
   

4. Mengupgrade server Userlock cadangan.

     c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $ulock2.NodeName
   

5. Validasi upgrade.

     $ulock1,$ulock2 | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   

Mengupgrade server Nessus.

Gunakan terminal PowerShell yang ada di CONFIG1

1. Buat array PowerShell yang berisi server Nessus.

     $role = 'nessus_'
     $nessus = $config.AllNodes | Where-Object {$_.role -match $role}
   

2. Upgrade server Nessus.

     $nessus | ForEach-Object {
     c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $_.NodeName}
   

3. Validasi upgrade.

     $nessus | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   

Mengupgrade server Hyper-V.

Gunakan terminal PowerShell yang ada di CONFIG1

1. Buat array PowerShell yang berisi server Hyper-V.

     $role = 'hyper_v'
     $hyper = $config.AllNodes | Where-Object {$_.role -eq $role}
   

2. Upgrade server Hyper-V.

     $hyper | ForEach-Object {
     c:\dsc\Update-RemoteHost.ps1 @sa_args -Computername $_.NodeName}
   

   Peringatan: Jika BM01 dimulai ulang, CONFIG1 akan dimulai ulang. Setelah tersedia, login, buka PowerShell sebagai Marvin, lalu jalankan langkah Config1 prep 1.e. untuk memuat ulang variabel. Mulai upgrade Hyper-V lagi.

3. Validasi upgrade.

     $hyper | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   

Mengupgrade Toolbox

Gunakan terminal PowerShell yang ada di CONFIG1

Catatan: v1.14 menyertakan drive tambahan di TOOLBOX1 yang perlu dibuat sebelum mengupdate DSC.

1. Buat array PowerShell yang berisi server Toolbox.

     $role = 'toolbox'
     $tools = $config.AllNodes | Where-Object {$_.role -eq $role}
   

2. Buat drive tambahan di server TOOLBOX1

     $tools | ForEach-Object {
        if ($_.ExtraDiskSize) {
        Invoke-Command -ComputerName $_.HyperVHost -Credential $sa_creds -ScriptBlock {
           $additional_disk_path = Join-Path -Path $using:_.ExtraDiskFolder -ChildPath "$($using:_.NodeName)-2.vhdx"
           New-VHD -Path $additional_disk_path -Dynamic -SizeBytes $using:_.ExtraDiskSize
           Add-VMHardDiskDrive -VMName $using:_.NodeName -Path $additional_disk_path
           Get-VMHardDiskDrive -VMName $using:_.NodeName | select VMName,ControllerLocation,Path
        }}}
   

   Pastikan output menampilkan dua disk yang ditetapkan ke VM. Contoh:

     VMName       ControllerLocation Path
     ------       ------------------ ----
     DC1-TOOLBOX1                  0 H:\Hyper-V\Virtual Hard Disks\DC1-TOOLBOX1.vhdx
     DC1-TOOLBOX1                  1 Z:\Hyper-V\Virtual Hard Disks\DC1-TOOLBOX1-2.vhdx
   

3. Upgrade server Toolbox.

     $tools | ForEach-Object {
     c:\dsc\Update-RemoteHost.ps1 @sa_args  -Computername $_.NodeName}
   

4. Validasi upgrade.

     $tools | ForEach-Object {
     $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
     Get-DscConfigurationStatus -CimSession $session}
   

Gunakan terminal PowerShell yang Ada di CONFIG1 untuk memvalidasi upgrade.

1. Pastikan DSC berjalan tanpa error.

      $role = 'domain_controller'
      $ca = 'ca_root'
      $dcs = $config.AllNodes | Where-Object {$_.role -eq $role}
      $non_dcs = $config.AllNodes | Where-Object {$_.role -ne $role -and $_.role -ne $ca -and $_.NodeName -ne "*"}
   
      $dcs | ForEach-Object {
      $session = New-CimSession -ComputerName $_.NodeName -Credential $da_creds
      Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState}
   
      $non_dcs | ForEach-Object {
      Write-Output "Checking $($_.NodeName)"
      $session = New-CimSession -ComputerName $_.NodeName -Credential $sa_creds
      Get-DscConfigurationStatus -CimSession $session | select HostName,Status,NumberOfResources,ResourcesNotInDesiredState | ft -AutoSize}
   

Mengupgrade VM Splunk

Peringatan: Lanjutkan upgrade OIC Splunk ini hanya dengan berkoordinasi dengan SIEM-G0008. Semua instance Splunk zonal dan OIC harus menggunakan versi minor yang sama agar dapat berfungsi dengan baik.

1. Dari jendela Powershell di CONFIG1, siapkan dan jalankan konfigurasi DSC:

   • Masukkan kode situs. Contoh: "DC1"

      $sitecode = Read-Host "Enter your site code"
      Set-Location c:\dsc
     

   • Konfigurasi penerus berat:

      $myargs = @{
      Computername = "$sitecode-HEAVYFWD"
      Credential = $sa_creds
      SetLcm = $true
      RemoveExisting = $true
      }
      .\Update-RemoteHost.ps1 @myargs
     

   • Konfigurasi pengindeks 1:

      $myargs = @{
      Computername = "$sitecode-INDEXER1"
      Credential = $sa_creds
      SetLcm = $true
      RemoveExisting = $true
      }
      .\Update-RemoteHost.ps1 @myargs
     

   • Konfigurasi pengindeks 2:

      $myargs = @{
      Computername = "$sitecode-INDEXER2"
      Credential = $sa_creds
      SetLcm = $true
      RemoveExisting = $true
      }
      .\Update-RemoteHost.ps1 @myargs
     

   • Konfigurasi pengindeks 3:

      $myargs = @{
      Computername = "$sitecode-INDEXER3"
      Credential = $sa_creds
      SetLcm = $true
      RemoveExisting = $true
      }
      .\Update-RemoteHost.ps1 @myargs
     

   • Konfigurasi pengelola:

      $myargs = @{
      Computername = "$sitecode-SPLUNKMGR"
      Credential = $sa_creds
      SetLcm = $true
      RemoveExisting = $true
      }
      .\Update-RemoteHost.ps1 @myargs
     

   • Konfigurasi searchhead:

      $myargs = @{
      Computername = "$sitecode-SEARCHHEAD"
      Credential = $sa_creds
      SetLcm = $true
      RemoveExisting = $true
      }
      .\Update-RemoteHost.ps1 @myargs
     

2. Dari jendela Powershell di CONFIG1, :

     $servers = @()
     $config.AllNodes | Where-Object {$_.role -match "splunk_"} | Foreach { $servers += $_.NodeName }
     Invoke-Command -ComputerName $servers -Credential $sa_creds -ScriptBlock {Restart-Service -Name 'Splunkd'} -ErrorAction Continue
   

3. Ikuti SIEM-G0006 untuk menyetel Pass4SymmKey global dan SIEM-G0007 untuk melampirkan setiap zona ke Splunk di OIC.

Mengupgrade Host CONFIG1

1. Dari jendela Powershell di CONFIG1, :

   Start-DscConfiguration -ComputerName $env:COMPUTERNAME -Path c:\config\mofs -Verbose -Wait -Force
   

2. Jika komputer dimulai ulang, login kembali dan mulai powershell lagi sebagai Marvin, lalu tingkatkan ke administrator. Isi variabel yang diperlukan untuk bagian berikutnya.

   Set-Location c:\dsc
   . c:\config\config.ps1
   $da_creds = (Get-Credential -Message "Provide domain admin credentials")
   $sa_creds = (Get-Credential -Message "Provide system admin credentials")
   

Microsoft Configuration Manager (MCM)

Peringatan: Microsoft Configuration Manager tidak dapat diupgrade.

Karena MCM bukan komponen yang dapat diupgrade, satu-satunya opsi adalah menghapus host MCM yang ada dan men-deploy ulang MCM.

• Pastikan software MCM saat ini telah di-hydrate setelah IT-T0023.

• Prosedur deployment ulang dibahas dalam IT-R0019.

Menghapus Checkpoint VM

Setelah upgrade selesai, titik pemeriksaan harus dihapus. Titik pemeriksaan dapat menyebabkan penggunaan disk yang berlebihan dari waktu ke waktu. Hanya pertahankan jika pemulihan ke titik pemeriksaan diperlukan karena upgrade gagal.

Gunakan terminal PowerShell yang ada di CONFIG1

1. Menghapus titik pemeriksaan VM.

     $config.AllNodes | Where-Object {$_.Role -eq "hyper_v"} | Foreach-Object {
     Invoke-Command -ComputerName $_.NodeName -Credential $sa_creds -Scriptblock {
       Get-VM | Get-VMSnapshot | Where-Object {$_.Name -like "Checkpoint_*"} | Remove-VMSnapshot -Verbose
     }}
   

Mengaktifkan kembali Objek kebijakan grup ke Domain

Gunakan terminal PowerShell yang ada di CONFIG1

1. Mengubah konfigurasi peran pengontrol domain untuk mengaktifkan link pada GPO terkelola

     $gpolinks = (Get-Content C:\dsc\data\GpoLinkMapping.yaml -Raw).Replace("LinkEnabled: 'No'", "LinkEnabled: 'Yes'")
     $gpolinks | Out-File C:\dsc\data\GpoLinkMapping.yaml -Force
   

2. Perbarui pengendali domain dengan peran ObjectOwner:

     c:\dsc\Update-RemoteHost.ps1 -Computername $config.AllNodes.DomainConfig.ObjectOwner -Credential $da_creds
   

Menghubungi tim Google

Lihat halaman Minta dukungan untuk mengetahui langkah-langkah menghubungi Google guna mendapatkan bantuan lebih lanjut.