15. Bootstrap penyimpanan objek

Perkiraan waktu penyelesaian: 7 jam

Pemilik komponen yang dapat dioperasikan: OBJ

Profil keterampilan: engineer deployment

Catatan: Tidak semua konfigurasi Google Distributed Cloud (GDC) dengan air gap dilengkapi dengan sistem StorageGRID. Instance Distributed Cloud dengan StorageGRID memiliki rak yang berisi perangkat StorageGRID dengan nomor model yang diawali dengan SG. Perangkat AFF ONTAP tidak dibahas di bagian ini.

15.1. Persyaratan jaringan

Lihat gambar berikut untuk diagram pengkabelan SG1000 dan SG6060 guna mengonfigurasi jaringan GRID, Admin, dan Klien:

15.1.1. Admin Node SG1000

Anda harus memiliki minimal dua node admin di SG1000.

Untuk setiap node admin, Anda harus memiliki total empat alamat IP, satu alamat di setiap alamat berikut:

• BMC Network.
• Jaringan Admin.
• Jaringan Klien.
• Jaringan Petak.

Anda harus memiliki tiga subnet untuk hal berikut:

• Jaringan Admin.
• BMC Network.

Jaringan Klien dan Jaringan Grid, serta setiap subnet harus memiliki subnet mask paling banyak 30 bit.

15.1.2. Node Penyimpanan SG6060 dan SG6000

Anda harus memiliki minimal tiga node penyimpanan untuk model SG6060 dan SG6000.

Untuk setiap node penyimpanan, Anda harus memiliki total lima alamat IP, satu alamat di setiap alamat berikut:

• Jaringan BMC(mgmt).
• Jaringan Admin(mgmt).
• Jaringan Petak.
• Jaringan Pengontrol Penyimpanan (mgmt). Catatan: Jaringan Pengontrol Penyimpanan harus memiliki dua alamat IP.

Anda harus memiliki dua subnet untuk masing-masing hal berikut:

• BMC Network.
• Jaringan Admin.
• Jaringan Pengontrol Penyimpanan.
• Jaringan Petak.

Tabel berikut mencantumkan jumlah alamat IP untuk node admin dan penyimpanan:

Jumlah IP yang diperlukan	Jaringan Admin	Jaringan Klien	Jaringan Petak
Admin Node	2	1	1
Node Penyimpanan	4	0	1

Anda harus memiliki tiga subnet berikut:

• Jaringan Admin.
• Jaringan Klien.
• Jaringan Petak.

Setiap subnet harus memiliki subnet mask maksimal 30 bit.

15.1.3. Detail jaringan

15.1.3.1. Jaringan Management Plane Distributed Cloud:

Jaringan pengelolaan Out-of-Band (OOB) Distributed Cloud berisi jaringan Object Storage Baseboard Management Controller (BMC) dan jaringan admin. Jaringan terhubung ke mgmtsw.

Anda harus memiliki alamat IP BMC OOB di setiap hal berikut:

• SG1000
• SG6000

Anda harus memiliki alamat IP Pengelolaan OOB di setiap hal berikut:

• SG1000
• SG6000
• SG6060

15.1.3.2. Jaringan bidang data Distributed Cloud

Jaringan bidang data terdiri dari LIF klien StorageGRID (SG1000) objek eksternal dan jaringan klien di NetApp.

Catatan: Jika Anda belum melakukannya, ikuti catatan di Membuat cellconfig untuk menggabungkan cellconfig yang dibuat ke dalam satu file.

• Pelajari langkah-langkah untuk mengidentifikasi SubnetClaim pada setiap bagian:

  • Endpoint API S3:
  1. Dalam file cellconfig, telusuri external-objectstorage-client-lif-subnet.
  2. Identifikasi SubnetClaim yang sesuai yang menentukan CIDR/alamat IP gateway yang ditetapkan.

  • Endpoint perangkat jaringan SG1000:

    1. Dalam file cellconfig, telusuri objectstorage-admin-nodes-lif-subnet.
    2. Identifikasi SubnetClaim yang sesuai yang menentukan alamat IP CIDR/gateway yang ditetapkan.

• Endpoint perangkat jaringan SG6060 grid:

  1. Dalam file cellconfig, telusuri objectstorage-storage-nodes-lif-subnet.
  2. Identifikasi SubnetClaim yang sesuai yang menentukan CIDR/alamat IP gateway yang ditetapkan.

15.2. Persiapan

15.2.1. Mengumpulkan informasi

Perkiraan waktu: 5 - 10 menit

Sebelum melanjutkan bagian ini, pastikan bootstrap dan konfigurasi jaringan menyelesaikan instance Distributed Cloud, dan Operator memiliki akses ke file cellconfig yang paling akurat atau terbaru yang tersedia, atau akses ke bootstrap.

15.2.1.1. Mengumpulkan Informasi Perangkat Hardware Penyimpanan

Instance Distributed Cloud mengikuti konvensi penamaan tetap untuk mengidentifikasi perangkat hardware dalam rak. Khususnya, ke perangkat penyimpanan objek berikut:

• Admin node(SG1000): <cell>-<rack>-objsadm[node-number]. Misalnya: af-ae-objsadm01 merepresentasikan node admin.
• Node pengontrol komputasi penyimpanan (SG6000-CN): <cell>-<rack>-objs[node-number]. Contoh: af-ae-objs01.
• Rak pengontrol penyimpanan(E2860): <cell>-<rack>-objs[node-number]-s1. Contoh: af-ae-objs01-s1
• Pengontrol node penyimpanan(SG6060): <cell>-<rack>-objs[node-number]-s1-[controller number]. Misalnya: af-ae-objs01-s1-01 dan af-ae-objs01-s1-02

15.2.1.2. Mengumpulkan Informasi Jaringan Management Plane

Selama bootstrap dan konfigurasi jaringan, Operator harus membuat subnet untuk bidang pengelolaan. Sistem penyimpanan objek memerlukan informasi berikut selama proses bootstrapping:

1. Subnet pengelolaan.
2. Alamat IP gateway pengelolaan.
3. 16 alamat IP yang dicadangkan di subnet pengelolaan, dua alamat IP untuk setiap node admin, dan empat alamat IP untuk setiap node penyimpanan.

Temukan alamat IP gateway Pengelolaan dari SubnetClaim <cell>-<rack>-mgmtsw01-objs-os-subnet. <cell> dan <rack> sama dengan yang diidentifikasi pada langkah "Kumpulkan Informasi Perangkat Hardware Penyimpanan" Misalnya: af-ae-mgmtsw01-objs-os-subnet

kubectl get subnetclaim -n root <cell>-<rack>-mgmtsw01-objs-os-subnet -o jsonpath='{.status.ipv4SubnetStatus.reservedIpRanges[?(.type == "GatewayReservation")].ipRange.startIPAddress}'

Simpan nilai perintah di MANAGEMENT_SWITCH_GATEWAY.

15.2.1.3. Mengumpulkan informasi jaringan bidang data

Sebelum melanjutkan, pastikan Anda telah menyediakan tiga subnet untuk sistem penyimpanan objek selama bootstrapping dan konfigurasi jaringan.

Periksa apakah subnet berikut ada:

• objectstorage-admin-nodes-lif-subnet
• objectstorage-storage-nodes-lif-subnet
• external-objectstorage-client-lif-subnet

Jalankan perintah berikut dengan nama SubnetClaim:

kubectl -n root get SubnetClaim SUBNET_CLAIM_NAME

Anda akan melihat output berikut:

NAME                                    CIDRCLAIM                             OVERLAY-NETWORK   IPV4-CIDR     IPV6-CIDR   VLAN   READY   VLANREADY
objectstorage-admin-nodes-lif-subnet   objectstorage-admin-nodes-lif-cidr   ObjectStorage     10.7.7.0/24                  7      True    True

Periksa apakah kolom berikut ada:

1. VLAN
2. READY: True
3. VLANREADY: True

15.2.1.4. Mengumpulkan informasi dependensi

Sistem penyimpanan objek mengandalkan layanan dan infrastruktur inti berikut di Distributed Cloud:

• NTP
• Modul keamanan hardware (HSM)
• DNS

15.2.1.5. Memperbarui kolom TO-BE-FILLED

Periksa file obj-cellobj.yaml untuk mengetahui nilai TO-BE-FILLED dan perbarui nilai tersebut.

Jalankan perintah berikut untuk memastikan nilai tidak ada dalam file YAML:

cat OBJ_CELLOBJ_YAML_PATH | grep "TO-BE-FILLED"

15.2.2. Jaringan pengelolaan konfigurasi melalui Koneksi Lokal

Perkiraan waktu: 30 - 45 menit

Subbagian ini menyiapkan jaringan pengelolaan untuk setiap node perangkat StorageGRID. Setelah jaringan pengelolaan dikonfigurasi, node StorageGRID diakses dari bootstrapper menggunakan IP di jaringan pengelolaan.

Ikuti langkah-langkah berikut untuk semua perangkat ObjectStorage:

• af-ae-objsadm01
• af-ae-objsadm02
• af-ae-objs01
• af-ae-objs02
• af-ae-objs03

Untuk mem-bootstrap perangkat StorageGRID, hubungkan ke setiap perangkat, termasuk dua node admin dan tiga node penyimpanan, dengan crash cart di Port 6 jaringan admin dan buka https://169.254.0.1:8443 untuk menyiapkan alamat IP admin di jaringan pengelolaan.

1. Hubungkan crash cart langsung ke port RJ-45 paling kanan di appliance layanan menggunakan kabel Ethernet. Diagram berikut menunjukkan Port 6 untuk node admin dan penyimpanan sebagai contoh:

   

   

2. Buka browser web di crash cart.

3. Buka https://169.254.0.1:8443 di setiap komputer.

   Catatan: Jika Anda tidak dapat mengakses Halaman beranda, coba ubah subnet mask crash cart menjadi 255.255.255.0, lalu coba lagi. Jika Anda masih tidak dapat mengaksesnya melalui koneksi lokal link, konfigurasi alamat IP crash cart sebagai 169.254.0.2, lalu coba lagi.

4. Dari panel menu Penginstal Appliance StorageGRID, klik Configure Networking > Link Configuration. Periksa apakah jaringan admin diaktifkan.

   

5. Untuk mengonfigurasi alamat IP untuk jaringan admin, pilih Configure Networking > IP Configuration.

6. Scroll ke bawah ke bagian Admin Network, lalu di IP Assignment, pilih Static dan masukkan alamat IP pengelolaan yang sesuai, managementIP, untuk node. Anda dapat menemukan IP pengelolaan untuk setiap node dalam file obj-cellobj.yaml. Contoh:

   • ObjectStorageAdminNode (SG1000):

     apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
     kind: ObjectStorageAdminNode
     metadata:
       creationTimestamp: null
       name: af-ae-objsadm01
     spec:
       network:
         bmcIP: 10.251.188.11/24
         clientIP: 10.251.113.2/28
         dataIP: 10.1.0.66/26
         managementIP: 10.251.188.10/24
       siteName: objectstorage-site
     

   • ObjectStorageStorageNode (SG6000):

     apiVersion: storagegrid.netapp.storage.private.gdc.goog/v1alpha1
     kind: ObjectStorageStorageNode
     metadata:
       creationTimestamp: null
       name: af-ae-objs01
     spec:
       network:
         bmcIP: 10.251.243.34/24
         controllerAManagementIP: 10.251.243.35/24
         controllerBManagementIP: 10.251.243.36/24
         dataIP: 10.1.0.132/26
         managementIP: 10.251.243.33/24
       siteName: objectstorage-site
     

   Catatan: Konfigurasi jaringan hanya untuk jaringan admin. Anda tidak perlu mengonfigurasi alamat IP lainnya.

   Tetapkan gateway sebagai MANAGEMENT_SWITCH_GATEWAY.

   Contoh gambar berikut menunjukkan konfigurasi untuk af-ae-objs01 menggunakan alamat IP pengelolaan yang dialokasikan dalam file obj-cellobj.yaml:

   

7. Klik Simpan dan verifikasi apakah alamat IP diperbarui.

8. Ping alamat IP pengelolaan dari bootstrapper untuk memastikan alamat IP tersebut dapat dijangkau.

   1. Ping alamat IP pengelolaan dari bootstrapper untuk memastikan alamat IP tersebut dapat dijangkau.
   2. Setelah semua node memiliki alamat IP di jaringan admin, akses GUI penginstalan node StorageGRID menggunakan alamat IP pengelolaannya.

Pemecahan Masalah:

Jika node tidak dapat di-ping:

1. Akses UI penginstalan node StorageGRID dari langkah 3 sebelumnya dan periksa apakah ada error yang ditampilkan di banner dialog. Coba atasi error. Hubungi engineer jika perlu.
2. Buka Configure Networking > IP Configuration. Pastikan bagian Jaringan Admin yang benar dikonfigurasi dengan IP Statis dan Gateway yang benar. Terkadang, node StorageGRID tidak sepenuhnya mendaftarkan konfigurasi jaringan pengelolaan setelah konfirmasi.
3. Lakukan langkah 5 - 8 lagi dan verifikasi jaringan node admin.

Akses ke GUI penginstalan node StorageGRID di setiap node diperlukan untuk melanjutkan penginstalan sistem penyimpanan objek.

15.2.3. Mengupgrade StorageGRID

Perkiraan waktu: 1 - 1,5 jam

Penting: Anda harus melakukan pemeriksaan versi di setiap node komputasi penyimpanan objek. Hal ini mencakup Node Admin (SG1000) dan Node Penyimpanan (SG6060).

Catatan: Anda harus melakukan downgrade ke versi penginstalan yang ditentukan jika versi StorageGRID saat ini lebih besar daripada versi yang diberikan.

Sebelum mengupgrade StorageGRID, periksa versi software StorageGRID. Buka Lanjutan > Upload Software StorageGRID. Anda akan melihat versi StorageGRID saat ini.

Periksa versi penginstalan StorageGRID yang disertakan:

gdcloud artifacts tree oci | grep object-storage/os

Output sampelnya mirip dengan berikut ini:

│   │   │       └── gpc-system-object-storage/os:11.8.0
    ├── gpc-system-object-storage/os:sha256-d4cb75f91f43a92cb580db98faae12e87ec49d2b27c7db8a056d6411ac3b6044.sig

Versi ditandai pada artefak, dalam contoh ini, sebagai 11.8.0:

Simpan nilai versi di SG_INSTALL_VERSION.

Periksa versi firmware StorageGRID yang disertakan:

gdcloud artifacts tree oci | grep object-storage/firmware

Output sampelnya mirip dengan berikut ini:

│   │   │       ├── gpc-system-object-storage/firmware:3.8.1
    ├── gpc-system-object-storage/firmware:sha256-20a664504c342b5f14188114fad7a1e7d40abc042690bb0f776aa67cecff52e1.sig

Versi ditandai pada artefak, dalam contoh ini, sebagai 3.8.1:

Simpan nilai versi di SG_FIRMWARE_VERSION.

Jika versi di node bukan SG_INSTALL_VERSION, lanjutkan ke langkah berikutnya untuk mengupgrade atau mendowngrade versi penginstalan StorageGRID. Jika versi saat ini adalah SG_INSTALL_VERSION, lanjutkan ke bagian Mengupgrade SANtricity.

15.2.3.1. Mengupgrade firmware

Ikuti langkah-langkah berikut untuk semua node StorageGRID:

• af-ae-objsadm01
• af-ae-objsadm02
• af-ae-objs01
• af-ae-objs02
• af-ae-objs03

1. Ambil image firmware dari paket:

   gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/firmware:SG_FIRMWARE_VERSION
   
   tar -xvzf storage/gpc-system-object-storage/firmware.tar.gz
   

   File tersedia di storagegrid_firmware_install/.

2. Buka Penginstal Perangkat StorageGRID di node StorageGRID. Pilih Lanjutan > Upgrade Firmware. Upload image firmware storagegrid_SG_FIRMWARE_VERSION_firmware_image.bin.tar.bz2 dan checksum storagegrid_SG_FIRMWARE_VERSION_firmware_checksum.bin.sha1 untuk versi firmware yang dipilih. Setelah mengupload, StorageGRID akan otomatis mulai memvalidasi file. Validasi biasanya memerlukan waktu sekitar lima hingga sepuluh menit.

   

3. Setelah dua tanda centang hijau muncul, klik Upgrade Partisi Tidak Aktif.

   

   Setelah menerima pesan Successfully updated the firmware on the inactive partition, pastikan partisi yang tidak aktif memang versi yang benar dengan melihat bagian Firmware Saat Ini.

   Klik Reboot dan Swap Partitions dua kali.

   Catatan: Selama proses mulai ulang dan penggantian, Anda mungkin kehilangan koneksi ke node untuk sementara. Proses ini berlangsung sekitar 20 - 30 menit hingga selesai. Jika koneksi dengan node tidak terputus, Anda mungkin perlu mengklik Mulai Ulang dan Tukar Partisi dua kali untuk memastikan permintaan berhasil.

4. Setelah node selesai di-reboot, ulangi langkah satu dan dua untuk mengupgrade firmware partisi lainnya. Partisi aktif adalah versi yang dipilih, sedangkan partisi tidak aktif berisi versi yang lebih lama.

   

15.2.3.2. Mengupgrade Software StorageGRID

Setelah upgrade firmware di semua node selesai ke versi yang benar, upgrade software ke versi yang dipilih di dua node admin. Anda tidak perlu mengupgrade node penyimpanan karena node tersebut meniru dan menarik software di node admin.

Ikuti petunjuk berikut di node admin untuk SG1000:

• af-ae-objsadm01
• af-ae-objsadm02

1. Ambil image penginstalan dari paket:

   gdcloud artifacts extract oci storage --image-name=gpc-system-object-storage/os:SG_INSTALL_VERSION
   
   tar -xvzf storage/gpc-system-object-storage/os.tar.gz
   

   File tersedia di storagegrid_os_install/.

2. Buka Advanced -> Upload StorageGRID Software. Klik Hapus untuk menghapus software saat ini, lalu upload paket software baru storagegrid_SG_INSTALL_VERSION_webscale_os_image.deb dan checksum yang sesuai storagegrid_SG_INSTALL_VERSION_webscale_os_checksum.deb.md5 seperti yang ditunjukkan:

   

3. Setelah software selesai diupload, pastikan software untuk node telah diupdate ke versi yang dipilih:

   

15.2.4. Mengupgrade SANtricity

Perkiraan waktu: 1 - 1,5 jam

Penting: Anda harus melakukan pemeriksaan versi di setiap SANtricity penyimpanan objek.

Sebelum mengupgrade SANtricity, periksa versi software SANtricity. Buka SANtricity UI, lalu klik Support > UPGRADE CENTER > Begin Upgrade. Versi SANtricity saat ini akan muncul.

Periksa versi penginstalan SANtricity yang dibundel:

gdcloud artifacts tree oci | grep object-storage/santricity

Output sampelnya mirip dengan berikut ini:

│   │   │       └── gpc-system-object-storage/santricity:11.70.5R1
    ├── gpc-system-object-storage/santricity:sha256-b145edeb8b24cac420862e7ef09224009aa51da6c6508f5a113753cc07db6ec5.sig

Versi ditandai pada artefak, dalam contoh ini, sebagai 11.70.5R1.

Simpan nilai versi di SANTRICITY_OS_VERSION.

Jika versi SANtricity lebih rendah dari SANTRICITY_OS_VERSION, lanjutkan ke langkah berikutnya untuk mengupgrade versi OS SANtricity. Jika tidak, lanjutkan ke Penginstalan.

Penting: Jika versi Anda saat ini lebih lama dari 11.70.5R1, dan versi target Anda lebih baru dari 11.70.5R1, Anda harus mengupgrade ke versi ini terlebih dahulu.

15.2.4.1. Mengupgrade SANtricity OS

Ikuti petunjuk berikut di UI SANtricity untuk setiap node penyimpanan:

1. Ambil image penginstalan dari paket:

   gdcloud artifacts extract oci santricity \
       --image-name=gpc-system-object-storage/santricity:SANTRICITY_OS_VERSION
   
   tar -xvzf santricity/gpc-system-object-storage/santricity.tar.gz
   

   File upgrade tersedia di santricity/SANTRICITY_OS_VERSION/.

2. Buka Dukungan > PUSAT UPGRADE. Klik Begin Upgrade dari SANtricity OS Software upgrade. Pilih file Software SANtricity OS dengan mengklik Browse. Upload paket software baru RCB_SANTRICITY_OS_VERSION_santricity_os_image.dlp seperti yang ditunjukkan:

   

3. Klik Mulai, lalu konfirmasi bahwa Anda ingin melakukan operasi.

4. Setelah upgrade selesai, verifikasi bahwa versi telah diupdate:

   

15.3. Penginstalan

15.3.1. Membuat Secret

Perkiraan waktu: 15 - 30 menit

Untuk mendapatkan nilai guna membuat secret, gunakan direktori cellcfg:

1. Dapatkan nama objectstoragestoragenodes:

   $ CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
   $ sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' CELLCFG_PATH/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
   

   Contoh output:

   # CELL_ID=$(kubectl get cells -n gpc-system -o jsonpath="{.items[0].metadata.name}")
   # sed -n '/kind: ObjectStorageStorageNode/, /status: {}/p' ./cellcfg/$CELL_ID-obj-cellobj.yaml | grep ' name:' | awk '{print $2}'
   ah-ac-objs01
   ah-ac-objs02
   ah-ac-objs03
   

2. Ambil alamat IP BMC untuk node penyimpanan:

   echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /bmcIP/p" $CELL_ID-obj-cellobj.yaml | grep bmcIP | awk '{print $2}' | cut -d'/' -f1):8443
   

3. Login ke pengelola sistem SANtricity dari link di output perintah sebelumnya. Jika Anda belum menyetel sandi sebelumnya, buat sandi dan login:

   

   1. Jika sandi SANtricity hilang, reset melalui konsol serial StorageGRID E2860. Untuk terhubung ke port serial array disk E2860, setelan terminalnya adalah 115200 8N1.

4. Konfigurasi alamat server NTP di pengelola sistem SANtricity untuk kedua pengontrol:

   

   1. Mengambil alamat server NTP

       kubectl get ntpserver -n ntp-system -o custom-columns=NAME:.metadata.name,MANAGEMENT-IP:.status.managementIP
       ```
      

   2. Pilih Hardware di pengelola sistem SANtricity.

   3. Jika grafik menampilkan drive, klik Tampilkan bagian belakang rak. Grafik akan berubah untuk menampilkan pengontrol, bukan drive.

   4. Klik pengontrol yang ingin Anda konfigurasi. Menu konteks pengontrol akan muncul.

   5. Pilih Konfigurasi server NTP. Dialog Configure Network Time Protocol (NTP) Server akan terbuka.

   6. Pilih Saya ingin mengaktifkan NTP di Controller (A atau B). Pilihan tambahan akan muncul dalam dialog.

   7. Pilih Tentukan alamat server NTP secara manual. Masukkan alamat server NTP utama menggunakan salah satu IP yang diambil oleh perintah sebelumnya.

   8. Klik Simpan.

5. Perbarui secret yang berisi kredensial SANtricity untuk setiap node penyimpanan dalam file cell.yaml. Jika rahasia tidak ada, tambahkan rahasia dengan mengikuti template ini:

   apiVersion: v1
   kind: Secret
   metadata:
     creationTimestamp: null
     name: <STORAGE_NODE_NAME>-santricity
     namespace: gpc-system
   stringData:
     password: 'PASSWORD'
     username: 'admin'
   type: Opaque
   

6. Buat secret untuk setiap node penyimpanan yang tercantum di langkah sebelumnya:

   kubectl create secret generic \
      --namespace=gpc-system STORAGE_NODE_NAME-santricity \
      --from-literal=username=admin \
      --from-literal=password=PASSWORD
   

Validasi:

1. Jalankan perintah berikut dengan setiap node penyimpanan yang tercantum di langkah sebelumnya. Perintah ini akan mencetak nama pengguna Santricity yang ditetapkan pada langkah sebelumnya. Validasi admin:

   kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.username}' | base64 -d; echo
   

2. Jalankan perintah berikut dengan setiap node penyimpanan yang tercantum di langkah sebelumnya. Perintah ini akan mencetak sandi Santricity:

   kubectl get secret -n gpc-system STORAGE_NODE_NAME-santricity -o jsonpath='{.data.password}' | base64 -d; echo
   

3. Jalankan perintah berikut untuk mendapatkan URL UI Pengelolaan Santricity. Login ke Santricity menggunakan nama pengguna dan sandi:

   echo https://$(sed -n "/name: STORAGE_NODE_NAME$/, /controllerAManagementIP/p" $CELL_ID-obj-cellobj.yaml | grep controllerAManagementIP | awk '{print $2}' | cut -d'/' -f1):8443
   

Pemecahan Masalah:

Jika rahasia tidak ditemukan saat menjalankan langkah validasi 1 atau 2, jalankan langkah kubectl create secret lagi.

Jika Anda tidak dapat login ke UI Pengelolaan Santricity:

1. Reset kredensial admin melalui konsol serial StorageGRID E2860.
2. Lakukan semua langkah sebelumnya kecuali langkah terakhir.

3. Hapus rahasia Santricity yang ada di setiap node:

   kubectl delete secret -n gpc-system STORAGE_NODE_NAME-santricity
   

4. Lakukan langkah terakhir untuk membuat ulang secret Santricity.

15.3.2. Mem-bootstrap Object Storage

Proses bootstrapping Object Storage bervariasi antara zona pertama dan zona yang bergabung. Lihat bagian yang relevan berdasarkan situasi spesifik Anda.

PENTING: Verifikasi bahwa bootstrapping API global zona anchor telah selesai sebelum melanjutkan.

15.3.2.1. Mem-bootstrap Object Storage di zona pertama

Jalankan perintah berikut untuk mem-bootstrap object storage:

gdcloud system objectstorage install --config /CELLCFG_PATH  --first-zone --enable-objectstorage-hsm -v 5

Catatan: Hapus tanda --enable-objectstorage-hsm jika lingkungan tidak di-bootstrap dengan HSM.

Catatan: Jika Anda melakukan bootstrap lingkungan sebelumnya secara manual, Anda mungkin mengalami error saat mengirimkan CertificateSigningRequest ke Kubernetes, menghapus CertificateSigningRequest, dan mencoba mengirim ulang. Jika hal ini terjadi, perbaiki masalah dengan merotasi sertifikat dari HSM. Untuk melakukan rotasi, ikuti petunjuk di HSM Toil 0012, di bagian Rotate KMIP certificates.

15.3.2.2. Mem-bootstrap Object Storage di zona gabungan

Pemecahan Masalah:

1. Jika perintah Google Cloud CLI mengalami waktu tunggu habis atau menampilkan error, selesaikan masalah yang ditampilkan.
2. Periksa pod gpc-system/obj-infra-cluster-cm-backend-controllerlogin untuk mengetahui detail error selengkapnya.

15.3.2.3. Mem-bootstrap Object Storage di zona gabungan

Perkiraan waktu: 30 - 60 menit

Mem-bootstrap Object Storage di zona gabungan memerlukan koordinasi antara rekonsiliasi Object Storage di zona anchor dan zona gabungan. Karena saluran komunikasi yang aman dan terkontrol antara dua zona untuk rekonsiliasi tidak ada selama waktu bootstrapping, IO harus memfasilitasi komunikasi yang aman untuk rekonsiliasi Object Storage antara dua zona secara manual.

1. Berikan peran bawaan Cluster Admin kepada diri Anda sendiri di cluster global dan cluster zonal root-admin di zona anchor. Lihat runbook IAM untuk mengetahui detailnya.

Atau, terapkan dua binding peran ini di zona anchor:

Di API global:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: mz-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: mz-bootstrap-global-backend-controllers-role
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: [e-mail]

Di cluster admin root:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: cluster-admin-binding
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: cluster-admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: [e-mail]

1. Jalankan perintah di zona anchor untuk mendapatkan IP server DNS, lalu catat untuk digunakan nanti: sh kubectl --kubeconfig /ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH get service gpc-coredns-external-udp -n dns-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

2. Siapkan resolver stub DNS zona gabungan untuk ditautkan dengan zona anchor:

   1. Nonaktifkan dan hentikan systemd-resolved sh systemctl disable systemd-resolved.service --now

   2. Hapus file resolv.conf jika ada sh rm -f /etc/resolv.conf

   3. Tulis IP server DNS zona anchor ke resolv.conf zona gabungan sh vim /etc/resolv.conf Contoh konten file /etc/resolv.conf: sh nameserver 10.200.40.0

3. Buat file YAML TokenRequest di zona gabungan.

   gdcloud system multi-zone create-token-request --zone JOINING_ZONE_NAME --client-type obj-join --cluster kind --namespace gpc-system --output-file TOKEN_REQUEST_YAML_PATH
   

   Ganti JOINING_ZONE_NAME dengan nama zona dari Kuesioner Penerimaan Pelanggan seperti yang dijelaskan dalam catatan di akhir bagian.

4. Transfer file YAML TokenRequest ke zona anchor.

   scp TOKEN_REQUEST_YAML_PATH ANCHOR_ZONE_NODE_IP:TOKEN_REQUEST_YAML_PATH
   

5. Terapkan YAML TokenRequest ke cluster global root-admin di zona anchor.

   kubectl --kubeconfig /GLOBAL_ROOT_ADMIN_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_REQUEST_YAML_PATH
   

6. Buat file YAML Token di zona anchor.

   gdcloud system multi-zone create-token --zone JOINING_ZONE_NAME --namespace gpc-system --output-file TOKEN_YAML_PATH
   

7. Transfer file YAML Token ke zona yang bergabung.

   scp TOKEN_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:TOKEN_YAML_PATH
   

8. Terapkan YAML Token ke cluster KIND di zona yang bergabung.

   kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f TOKEN_YAML_PATH
   

9. Buat file YAML ObjectStorageBootstrap di zona anchor.

   gdcloud system objectstorage create-bootstrap --output-file  OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
   

10. Transfer file YAML ObjectStorageBootstrap ke zona yang bergabung.

    scp OBJECT_STORAGE_BOOTSTRAP_YAML_PATH JOINING_ZONE_BOOTSTRAP_NODE_IP:OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    

11. Terapkan file YAML ObjectStorageBootstrap ke cluster KIND di zona gabungan.

    kubectl --kubeconfig /KIND_CLUSTER_KUBECONFIG_PATH apply -f OBJECT_STORAGE_BOOTSTRAP_YAML_PATH
    

12. Bootstrapping Object Storage di zona gabungan.

    gdcloud system objectstorage install --config /CELLCFG_PATH  --add-zone --enable-objectstorage-hsm -v 5
    

    Catatan: Hapus tanda --enable-objectstorage-hsm jika lingkungan tidak di-bootstrap dengan HSM.

Catatan: Jika Anda melakukan bootstrap lingkungan sebelumnya secara manual, Anda mungkin mengalami error saat mengirimkan CertificateSigningRequest ke Kubernetes, menghapus CertificateSigningRequest, dan mencoba mengirim ulang. Jika hal ini terjadi, perbaiki masalah dengan merotasi sertifikat dari HSM. Untuk melakukan rotasi, ikuti petunjuk di HSM Toil 0012, di bagian Rotate KMIP certificates.

Catatan: objectstorageadminnode, objectstoragestoragenode, dan objectstoragesite diharapkan tidak dalam status Siap di cluster KIND.