Get best of the week

VMware vSAN 6.7 - Dan guntur melanda

Tahun 2018 berakhir ...

Suatu hari, pada hari yang cerah di bulan Desember, Perusahaan kami memutuskan untuk membeli perangkat keras baru. Tidak, tentu saja, ini tidak terjadi dalam semalam. Keputusan itu dibuat sebelumnya. Jauh lebih awal. Namun, seperti biasa, keinginan kita tidak selalu bertepatan dengan kemampuan pemegang saham. Dan tidak ada uang, dan kami bertahan. Tapi akhirnya, saat yang menyenangkan itu datang ketika akuisisi disetujui di semua tingkatan. Semuanya baik-baik saja, pekerja kerah putih bertepuk tangan dengan gembira, mereka bosan memproses dokumen selama 25 jam setiap bulan di server berusia 7 tahun, dan mereka dengan gigih meminta Departemen TI untuk membuat sesuatu untuk memberi mereka lebih banyak waktu untuk hal-hal lain yang sama pentingnya .

Kami berjanji untuk mengurangi waktu pemrosesan dokumen hingga 3 kali, hingga 8 jam. Untuk ini, seekor burung gereja ditembakkan dari meriam. Opsi ini tampaknya satu-satunya, karena tim kami tidak, dan tidak pernah, administrator database untuk menerapkan semua jenis optimasi kueri (DBA).

Konfigurasi peralatan yang dipilih, tentu saja, setinggi langit. Ini adalah tiga server dari perusahaan HPE - DL560 Gen10. Masing-masing dari mereka membual 4 prosesor Intel Xeon Platinum 8164 2.0Ghz dengan 26 core, 256 DDR4 RAM, serta 8 SSD 800Gb SAS (800Gb WD Ultrastar DC SS530 WUSTR6480ASS204 SSD) + 8 SSD 1.92Tb (Western Digital Ultrastar DC SS530 )

"Potongan besi" ini dimaksudkan untuk kluster VMware (HA + DRS + vSAN). Yang telah bekerja bersama kami selama hampir 3 tahun di server yang sama dari generasi ke-7 dan ke-8, juga dari HPE. Ngomong-ngomong, tidak ada masalah sampai HPE menolak untuk mendukung mereka dan meningkatkan ESXi dari versi 6.0, bahkan menjadi 6.5, tanpa rebana. Yah, oke, sebagai hasilnya, mungkin untuk memperbarui. Dengan mengubah gambar instalasi, menghapus modul masalah yang tidak kompatibel dari gambar instalasi, dll. Ini juga menambah bahan bakar ke api keinginan kami untuk mencocokkan segalanya yang baru. Tentu saja, jika itu bukan untuk "trik" vSAN baru, di peti mati kami melihat pembaruan seluruh sistem dari versi 6.0 ke yang lebih baru, dan tidak perlu menulis artikel, tetapi kami tidak mencari cara mudah ...

Jadi, kami membeli peralatan ini dan memutuskan untuk mengganti yang sudah usang. Kami menerapkan SPP terakhir untuk setiap server baru, yang dipasang di masing-masingnya dua kartu jaringan Ethernet 10G (satu untuk jaringan pengguna, dan yang kedua untuk SAN, 656596-B21 HP Ethernet 10Gb 2-port 530T). Ya, setiap server baru datang dengan kartu jaringan SFP + tanpa modul, tetapi infrastruktur jaringan kami menyiratkan Ethernet (dua tumpukan sakelar DELL 4032N untuk jaringan LAN dan SAN), dan distributor HP di Moskow tidak memiliki modul HPE 813874-B21 dan kami mereka tidak menunggu.

Ketika tiba saatnya untuk menginstal ESXi dan memasukkan node baru ke dalam pusat data VMware umum, sebuah "keajaiban" terjadi. Ternyata, HPE ESXi Custom ISO versi 6.5 dan di bawah ini tidak dirancang untuk diinstal pada server Gen10 baru. Hardcore saja, hanya 6,7. Dan kami tanpa sadar harus mengikuti sila "perusahaan virtual".

Cluster HA + DRS baru telah dibuat, kluster vSAN telah dibuat, semua sesuai dengan VMware HCL dan dokumen ini . Semuanya dikonfigurasikan berdasarkan Feng Shui dan hanya "alarm" berkala yang mencurigakan dalam memonitor vSAN tentang nilai parameter yang tidak nol di bagian ini:

gambar

Kami, dengan tenang, memindahkan semua mesin virtual (sekitar 50 buah) ke server baru dan ke penyimpanan vSAN baru yang dibangun pada disk SSD, kami memeriksa kinerja pemrosesan dokumen di lingkungan baru (omong-omong, ternyata menghemat lebih banyak waktu daripada yang kami rencanakan) . Sampai pangkalan terberat dipindahkan ke cluster baru, operasi, yang disebutkan di awal artikel, memakan waktu sekitar 4 jam, bukannya 25! Ini merupakan kontribusi yang signifikan terhadap suasana Tahun Baru semua peserta dalam proses tersebut. Beberapa mungkin mulai memimpikan hadiah. Kemudian semua orang dengan senang hati pergi untuk liburan Tahun Baru.

Ketika hari kerja tahun baru 2019 dimulai, tidak ada yang menandakan malapetaka. Semua layanan, ditransfer ke kapasitas baru, tanpa berlebihan, lepas landas! Hanya peristiwa di bagian re-sinkronisasi objek menjadi lebih. Dan setelah beberapa minggu masalah terjadi. Di pagi hari, hampir semua layanan utama Perusahaan (1s, MSSQL, SMB, Exchange, dll.) Berhenti merespons, atau mulai merespons dengan penundaan yang lama. Seluruh infrastruktur jatuh ke dalam kekacauan total, dan tidak ada yang tahu apa yang terjadi dan apa yang harus dilakukan. Semua mesin virtual di vCenter tampak "hijau", tidak ada kesalahan dalam pemantauan mereka. Mem-boot ulang tidak membantu. Selain itu, setelah reboot, beberapa mesin bahkan tidak bisa boot, menampilkan berbagai kesalahan proses di konsol. Neraka tampaknya mendatangi kami dan iblis sedang menggosok tangannya untuk mengantisipasi.

Di bawah tekanan stres yang serius, adalah mungkin untuk menentukan sumber bencana. Masalah ini ternyata adalah penyimpanan terdistribusi vSAN. Kerusakan data yang tidak terkendali pada disk mesin virtual terjadi, sekilas - tanpa alasan. Pada saat itu, satu-satunya solusi yang tampaknya rasional adalah dengan menghubungi dukungan teknis VMware dengan jeritan: SOS, save-help!

Dan keputusan ini, selanjutnya, menyelamatkan Perusahaan dari hilangnya data yang relevan, termasuk kotak surat karyawan, database, dan file bersama. Bersama-sama, kita berbicara tentang 30+ terabyte informasi.

Dia berkewajiban membayar upeti kepada staf pendukung VMware yang tidak “bermain sepak bola” dengan pemegang langganan dukungan teknis dasar, tetapi memasukkan kasus ini ke dalam segmen Enterpise, dan prosesnya berputar sepanjang waktu.

Apa yang terjadi selanjutnya:

  1. Dukungan teknis VMware mengajukan dua pertanyaan utama: bagaimana memulihkan data dan bagaimana memecahkan masalah korupsi data "phantom" dalam disk mesin virtual di cluster tempur "vSAN". Ngomong-ngomong, data itu tidak bisa dipulihkan, karena penyimpanan tambahan ditempati oleh salinan cadangan dan tidak ada tempat untuk menyebarkan layanan "tempur".
  2. Sementara saya, bersama-sama dengan VMware, mencoba mengumpulkan benda-benda yang "rusak" di kluster vSAN, rekan-rekan saya mendesak untuk menambang penyimpanan baru yang dapat menampung semua 30+ terabyte data Perusahaan.
  3. , , VMware , , «» - - . , ?
  4. .
  5. , « » .
  6. , , «» .
  7. Saya harus sementara (selama beberapa hari) mengorbankan efisiensi surat, demi tambahan 6 terabyte ruang kosong di toko, untuk meluncurkan layanan utama yang menjadi sandaran pendapatan Perusahaan.
  8. Ribuan baris obrolan dengan rekan kerja berbahasa Inggris dari VMware disimpan "untuk memori", berikut adalah kutipan singkat dari percakapan kami:

I understood that you are now migrating all the VMs out of vSAN datastore.
May I know, how the migration task is going on.? How many VMs left and how much time is expected to migrate the remaining VMs. ?
There are 6 vms still need to be migrated. 1 of them is fail so far.
How much time is expected to complete the migration for the working VMs..?
I think atleast 2-3 hours
ok
Can you please SSH to vCenter server ?
you on it
/localhost/Datacenter ###CLUB/computers/###Cluster> vsan.check_state .
2019-02-02 05:22:34 +0300: Step 1: Check for inaccessible vSAN objects
Detected 3 objects to be inaccessible
Detected 7aa2265c-6e46-2f49-df40-20677c0084e0 on esxi-dl560-gen10-2.####.lan to be inaccessible
Detected 99c3515c-bee0-9faa-1f13-20677c038dd8 on esxi-dl560-gen10-3.####.lan to be inaccessible
Detected f1ca455c-d47e-11f7-7e90-20677c038de0 on esxi-dl560-gen10-1.####.lan to be inaccessible
2019-02-02 05:22:34 +0300: Step 2: Check for invalid/inaccessible VMs
Detected VM 'i.#####.ru' as being 'inaccessible'
2019-02-02 05:22:34 +0300: Step 3: Check for VMs for which VC/hostd/vmx are out of sync
Did not find VMs for which VC/hostd/vmx are out of sync
/localhost/Datacenter ###CLUB/computers/###Cluster>
Thank you
second vm with issues: sd.####.ru

Bagaimana masalah ini terwujud (di samping layanan organisasi yang telah runtuh dengan kuat).

Pertumbuhan eksponensial kesalahan checksum (CRC) "tiba-tiba" selama pertukaran data dengan disk dalam mode HBA. Cara memeriksa ini - masukkan perintah berikut di konsol setiap node ESXi:

while true; do clear; for disk in $(localcli vsan storage list | grep -B10 'ity Tier: tr' |grep "VSAN UUID"|awk '{print $3}'|sort -u);do echo ==DISK==$disk====;vsish -e get /vmkModules/lsom/disks/$disk/checksumErrors | grep -v ':0';done; sleep 3; done

Sebagai hasil dari eksekusi, Anda dapat melihat kesalahan CRC untuk setiap disk di kluster vSAN dari simpul ini (nilai nol tidak akan ditampilkan). Jika Anda memiliki nilai positif, dan terlebih lagi, nilai-nilai itu terus tumbuh, maka ada alasan untuk tugas yang terus-menerus muncul di Monitor -> vSAN -> Bagian objek yang disejajarkan dengan cluster.

Bagaimana memulihkan disk mesin virtual yang tidak mengkloning atau bermigrasi dengan cara standar?

Siapa yang akan berpikir menggunakan perintah kucing yang kuat:

1. cd      vSAN
[root@esxi-dl560-gen10-1:~] cd /vmfs/volumes/vsanDatastore/estaff

2. grep vmdk     uuid

[root@esxi-dl560-gen10-1:/vmfs/volumes/vsan:52f53dfd12dddc84-f712dbefac32cd1a/2636a75c-e8f1-d9ca-9a00-20677c0084e0] grep vsan *vmdk
estaff.vmdk:RW 10485760 VMFS "vsan://3836a75c-d2dc-5f5d-879c-20677c0084e0"
estaff_1.vmdk:RW 41943040 VMFS "vsan://3736a75c-e412-a6c8-6ce4-20677c0084e0"
[root@esxi-dl560-gen10-1:/vmfs/volumes/vsan:52f53dfd12dddc84-f712dbefac32cd1a/2636a75c-e8f1-d9ca-9a00-20677c0084e0]

3.    VM  ,  :

mkdir /vmfs/volumes/POWERVAULT/estaff

4.   vmx  

cp *vmx *vmdk /vmfs/volumes/POWERVAULT/estaff

5.      ,      ^_^

/usr/lib/vmware/osfs/bin/objtool open -u 3836a75c-d2dc-5f5d-879c-20677c0084e0; sleep 1; cat /vmfs/devices/vsan/3836a75c-d2dc-5f5d-879c-20677c0084e0 >> /vmfs/volumes/POWERVAULT/estaff/estaff-flat.vmdk

6. cd   :

 cd /vmfs/volumes/POWERVAULT/estaff

7.    - estaff.vmdk     

[root@esxi-dl560-gen10-1:/tmp] cat estaff.vmdk
# Disk DescriptorFile
version=4
encoding="UTF-8"
CID=a7bb7cdc
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 10485760 VMFS "vsan://3836a75c-d2dc-5f5d-879c-20677c0084e0"      <<<<<     "estaff-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "ide"
ddb.deletable = "true"
ddb.geometry.cylinders = "10402"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.longContentID = "6379fa7fdf6009c344bd9a64a7bb7cdc"
ddb.thinProvisioned = "1"
ddb.toolsInstallType = "1"
ddb.toolsVersion = "10252"
ddb.uuid = "60 00 C2 92 c7 97 ca ae-8d da 1c e2 3c df cf a5"
ddb.virtualHWVersion = "8"
[root@esxi-dl560-gen10-1:/tmp]

Cara mengenali naa.xxxx ... disk dalam grup disk:

[root@esxi-dl560-gen10-1:/vmfs/volumes] vdq -Hi
Mappings:
   DiskMapping[0]:
           SSD:  naa.5000c5003024eb43
            MD:  naa.5000cca0aa0025f4
            MD:  naa.5000cca0aa00253c
            MD:  naa.5000cca0aa0022a8
            MD:  naa.5000cca0aa002500

   DiskMapping[2]:
           SSD:  naa.5000c5003024eb47
            MD:  naa.5000cca0aa002698
            MD:  naa.5000cca0aa0029c4
            MD:  naa.5000cca0aa002950
            MD:  naa.5000cca0aa0028cc

   DiskMapping[4]:
           SSD:  naa.5000c5003024eb4f
            MD:  naa.5000c50030287137
            MD:  naa.5000c50030287093
            MD:  naa.5000c50030287027
            MD:  naa.5000c5003024eb5b
            MD:  naa.5000c50030287187

Cara mengetahui vUAN UUID untuk setiap negara ....:

[root@esxi-dl560-gen10-1:/vmfs/volumes] localcli vsan storage list | grep -B15 'ity Tier: tr' | grep -E '^naa|VSAN UUID'

naa.5000cca0aa002698:
   VSAN UUID: 52247b7d-fed5-a2f2-a2e8-5371fa7ef8ed
naa.5000cca0aa0029c4:
   VSAN UUID: 52309c55-3ecc-3fe8-f6ec-208701d83813
naa.5000c50030287027:
   VSAN UUID: 523d7ea5-a926-3acd-2d58-0c1d5889a401
naa.5000cca0aa0022a8:
   VSAN UUID: 524431a2-4291-cb49-7070-8fa1d5fe608d
naa.5000c50030287187:
   VSAN UUID: 5255739f-286c-8808-1ab9-812454968734
naa.5000cca0aa0025f4: <<<<<<<
   VSAN UUID: 52b1d17e-02cc-164b-17fa-9892df0c1726
naa.5000cca0aa00253c:
   VSAN UUID: 52bd28f3-d84e-e1d5-b4dc-54b75456b53f
naa.5000cca0aa002950:
   VSAN UUID: 52d6e04f-e1af-cfb2-3230-dd941fd8a032
naa.5000c50030287137:
   VSAN UUID: 52df506a-36ea-f113-137d-41866c923901
naa.5000cca0aa002500:
   VSAN UUID: 52e2ce99-1836-c825-6600-653e8142e10f
naa.5000cca0aa0028cc:
   VSAN UUID: 52e89346-fd30-e96f-3bd6-8dbc9e9b4436
naa.5000c50030287093:
   VSAN UUID: 52ecacbe-ef3b-aa6e-eba3-6e713a0eb3b2
naa.5000c5003024eb5b:
   VSAN UUID: 52f1eecb-befa-12d6-8457-a031eacc1cab

Dan yang paling penting.

Masalahnya ternyata adalah pengoperasian firmware dari pengontrol RAID yang salah dan driver HPE dengan vSAN.
Sebelumnya, di VMware 6.7 U1, firmware yang kompatibel untuk HPE Smart Array P816i-a SR Gen10 controller di vSAN HCL adalah versi 1.98 (yang ternyata berakibat fatal bagi organisasi kami), dan sekarang dikatakan 1.65 .
Selain itu, versi 1.99, yang memecahkan masalah pada waktu itu (31 Januari 2019), sudah ada di nampan HPE, tetapi mereka tidak meneruskannya ke VMware atau kami, dengan alasan kurangnya sertifikasi, terlepas dari penolakan kami dan semua itu. , kata mereka, hal utama bagi kami adalah menyelesaikan masalah dengan penyimpanan dan hanya itu.

Akibatnya, masalah akhirnya diselesaikan hanya setelah tiga bulan, ketika versi firmware 1,99 untuk pengontrol disk dirilis!

Kesimpulan apa yang saya ambil?

  1. ( ), .
  2. ! .
  3. «» , «» «» , 30% «».
  4. HPE, , .
  5. , :

    • HPE - . , Enterprise . , , ).
    • Saya tidak melihat situasi di mana ruang disk tambahan mungkin diperlukan untuk menempatkan salinan semua server Perusahaan jika terjadi keadaan darurat.
  6. Selain itu, mengingat apa yang telah terjadi, untuk VMware saya tidak akan lagi membeli perangkat keras untuk perusahaan besar, vendor apa pun selain DELL. Mengapa, karena DELL, sejauh yang saya tahu, mengakuisisi VMware, dan sekarang integrasi perangkat keras dan perangkat lunak ke arah ini diharapkan sedekat mungkin.

Seperti yang mereka katakan, dibakar dalam susu, meniup ke dalam air.

Itu semuanya. Saya berharap Anda tidak pernah masuk ke dalam situasi yang begitu mengerikan.

Seingat saya, saya sudah akan terkejut!

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles