🙆 👱🏿 💅🏿 VMware vSAN 6.7 - और गड़गड़ाहट हुई 🤱🏾 🙅🏿 🏇

वर्ष 2018 समाप्त हो रहा था ...

एक बार, दिसंबर के एक स्पष्ट दिन पर, हमारी कंपनी ने एक नया हार्डवेयर खरीदने का फैसला किया। नहीं, ज़ाहिर है, यह रातोंरात नहीं हुआ। निर्णय पहले किया गया था। बहुत पहले। लेकिन, हमेशा की तरह, हमारी इच्छाएं शेयरधारकों की क्षमताओं से मेल नहीं खातीं। और कोई पैसा नहीं था, और हम पर आयोजित किया। लेकिन आखिरकार, वह खुशी का पल आया जब अधिग्रहण को सभी स्तरों पर मंजूरी मिल गई। सब कुछ ठीक था, सफेदपोश श्रमिकों ने खुशी से तालियां बजाईं, वे 7-वर्षीय सर्वर पर मासिक रूप से 25 घंटे के लिए दस्तावेजों के प्रसंस्करण से थक गए थे, और उन्होंने आईटी विभाग को बहुत दृढ़ता के साथ कहा कि वे अन्य के लिए अधिक समय देने के लिए कुछ के साथ आएं, समान रूप से महत्वपूर्ण चीजें ।

हमने प्रसंस्करण दस्तावेजों के लिए समय को 3 गुना, 8 घंटे तक कम करने का वादा किया था। इसके लिए, एक तोप से एक गौरैया को निकाल दिया गया था। यह विकल्प केवल एक ही लग रहा था, क्योंकि हमारी टीम ने नहीं किया था, और कभी भी, सभी प्रकार के क्वेरी ऑप्टिमाइज़ेशन (डीबीए) को लागू करने के लिए एक डेटाबेस व्यवस्थापक नहीं था।

चयनित उपकरणों का विन्यास, निश्चित रूप से, आकाश-उच्च था। ये HPE कंपनी के तीन सर्वर थे - DL560 Gen10। उनमें से प्रत्येक ने 26 कोर, 256 DDR4 रैम के साथ 4 इंटेल Xeon प्लेटिनम 8164 2.0Ghz प्रोसेसर, साथ ही 8 SSD 800Gb SAS (800Gb WD Ultrastar DC SS530 WUSTR648080204 SSD) + 8 1.92Tb SSD (वेस्टर्न डिजिटल अल्ट्रास्टार डीसी SS530) का दावा किया। )

ये "लोहे के टुकड़े" VMware क्लस्टर (HA + DRS + vSAN) के लिए थे। जो 7 वीं और 8 वीं पीढ़ी के समान सर्वरों पर लगभग 3 वर्षों से हमारे साथ काम कर रहा है, वह भी एचपीई से। वैसे, तब तक कोई समस्या नहीं थी जब तक कि एचपीई ने उन्हें समर्थन देने से इनकार नहीं किया और ईएसएक्सआई को संस्करण 6.0 से, यहां तक कि 6.5 से, एक टैम्बोरिन के बिना अपग्रेड किया। ठीक है, ठीक है, परिणामस्वरूप, अद्यतन करना संभव था। इंस्टॉलेशन छवि को बदलकर, इंस्टॉलेशन छवि से असंगत समस्या मॉड्यूल को दूर करना, आदि। इसने सब कुछ नया करने की हमारी इच्छा की आग में ईंधन भी डाला। बेशक, अगर यह नए vSAN "ट्रिक्स" के लिए नहीं था, तो ताबूत में हमने संस्करण 6.0 से पूरे सिस्टम का एक अद्यतन एक नए सिरे से देखा, और एक लेख लिखने की कोई आवश्यकता नहीं होगी, लेकिन हम आसान तरीके नहीं देख रहे हैं ...

इसलिए, हमने इस उपकरण को खरीदा और लंबे समय से अप्रचलित को बदलने का फैसला किया। हमने प्रत्येक नए सर्वर पर अंतिम एसपीपी लागू किया , उनमें से प्रत्येक में दो ईथरनेट 10 जी नेटवर्क कार्ड (उपयोगकर्ता नेटवर्क के लिए एक, और सैन, 656596-बी 21 एचपी ईथरनेट 10 जीबी 2-पोर्ट 530 टी) के लिए दूसरा लागू किया गया। हां, प्रत्येक नया सर्वर मॉड्यूल के बिना एक एसएफपी + नेटवर्क कार्ड के साथ आया था, लेकिन हमारे नेटवर्क के बुनियादी ढांचे ने ईथरनेट (लैन और सैन नेटवर्क के लिए डेल 4032N स्विच के दो ढेर) का अर्थ लगाया था, और मास्को में एचपी वितरक के पास एचपीई 813874-B21 मॉड्यूल नहीं था और हम उन्होंने इंतजार नहीं किया।

जब ESXi को स्थापित करने और एक सामान्य VMware डेटा केंद्र में नए नोड को शामिल करने का समय आया, तो एक "चमत्कार" हुआ। जैसा कि यह निकला, HPE ESXi कस्टम आईएसओ संस्करण 6.5 और नीचे नए Gen10 सर्वर पर स्थापित होने के लिए डिज़ाइन नहीं किया गया है। केवल कट्टर, केवल 6.7। और हमें अनजाने में "आभासी कंपनी" की प्रस्तावना का पालन करना था।

एक नया हा + डीआरएस क्लस्टर बनाया गया था, एक वीएसएएन क्लस्टर बनाया गया था, सभी वीएमवेयर एचसीएल और इस दस्तावेज के साथ सख्त अनुपालन में थे । सब कुछ फेंगशुई के अनुसार कॉन्फ़िगर किया गया था और केवल आवधिक "अलार्म" इस खंड में गैर-शून्य पैरामीटर मानों के बारे में vSAN की निगरानी में संदिग्ध थे:

हम, मन की शांति के साथ, सभी वर्चुअल मशीनों (लगभग 50 टुकड़े) को नए सर्वरों में ले गए और SSD डिस्क पर निर्मित एक नए vSAN स्टोरेज के लिए, हमने नए वातावरण में दस्तावेज़ प्रसंस्करण के प्रदर्शन की जाँच की (वैसे, यह हमारी योजना की तुलना में बहुत अधिक समय बचाने के लिए निकला) । जब तक सबसे बड़े आधार को नए क्लस्टर में स्थानांतरित नहीं किया गया, तब तक ऑपरेशन, जिसका उल्लेख लेख की शुरुआत में किया गया था, 25 के बजाय लगभग 4 घंटे लग गए! इस प्रक्रिया में सभी प्रतिभागियों के नए साल के मूड में महत्वपूर्ण योगदान था। कुछ शायद पुरस्कार का सपना देखने लगे। फिर सभी खुशी से नए साल की छुट्टियों के लिए रवाना हुए।

जब नए साल 2019 के सप्ताह के दिन शुरू हुए, तो कुछ भी नहीं था। सभी सेवाओं, अतिशयोक्ति के बिना, नई क्षमताओं में स्थानांतरित कर दिया गया! वस्तुओं के पुन: सिंक्रनाइज़ेशन अनुभाग में केवल घटनाएं बहुत अधिक हो गईं। और कुछ हफ़्ते के बाद परेशानी हुई। सुबह के समय, कंपनी की लगभग सभी प्रमुख सेवाओं (1s, MSSQL, SMB, Exchange, आदि) ने प्रतिक्रिया देना बंद कर दिया, या एक लंबी देरी के साथ जवाब देना शुरू कर दिया। पूरा बुनियादी ढांचा पूरी तरह अराजकता में डूब गया, और किसी को नहीं पता था कि क्या हुआ और क्या करना है। VCenter की सभी आभासी मशीनों में "हरा" दिखता था, उनकी निगरानी में कोई त्रुटि नहीं थी। रिबूट करने से कोई फायदा नहीं हुआ। इसके अलावा, रिबूट के बाद, कुछ मशीनें बूट भी नहीं कर सकती थीं, जो कंसोल में विभिन्न प्रक्रिया त्रुटियों को प्रदर्शित करती हैं। नरक हमें प्रतीत हुआ और शैतान प्रत्याशा में अपने हाथ रगड़ रहा था।

गंभीर तनाव के दबाव में, आपदा के स्रोत को निर्धारित करना संभव था। यह समस्या vSAN वितरित संग्रहण के रूप में सामने आई। वर्चुअल मशीन डिस्क पर अनियंत्रित डेटा भ्रष्टाचार, पहली नज़र में - बिना किसी कारण के। उस समय, एकमात्र समाधान जो तर्कसंगत लग रहा था वह चीख के साथ वीएमवेयर तकनीकी सहायता से संपर्क करना था: एसओएस, सेव-हेल्प!

और इस निर्णय ने, बाद में कंपनी को कर्मचारी मेलबॉक्स, डेटाबेस और साझा फ़ाइलों सहित प्रासंगिक डेटा के नुकसान से बचाया। साथ में, हम 30+ टेराबाइट्स की जानकारी के बारे में बात कर रहे हैं।

वह वीएमवेयर सपोर्ट स्टाफ को श्रद्धांजलि देने के लिए बाध्य है, जो मूल तकनीकी सहायता सदस्यता के मालिक "फुटबॉल" नहीं थे, लेकिन इस मामले को एंटरपेज़ खंड में शामिल किया गया था, और प्रक्रिया घड़ी के आसपास घूमती थी।

आगे क्या हुआ:

VMware के तकनीकी समर्थन में दो मुख्य प्रश्न हैं: डेटा को कैसे पुनर्प्राप्त करें और "vSAN" कॉस्ट क्लस्टर में वर्चुअल मशीन डिस्क में "प्रेत" डेटा भ्रष्टाचार की समस्या को कैसे हल करें। वैसे, डेटा पुनर्प्राप्त करने के लिए कहीं नहीं था, क्योंकि अतिरिक्त प्रतियां बैकअप प्रतियों द्वारा कब्जा कर लिया गया था और "मुकाबला" सेवाओं को तैनात करने के लिए कहीं नहीं था।
हालांकि, वीएमवेयर के साथ मिलकर, वीएसएएन क्लस्टर में "क्षतिग्रस्त" वस्तुओं को एक साथ रखने की कोशिश की, मेरे सहयोगियों ने तुरंत एक नया भंडारण खनन किया जो कंपनी डेटा के सभी 30+ टेराबाइट्स को समायोजित कर सकता है।
, , VMware , , «» - - . , ?
.
, « » .
, , «» .
मुझे अस्थायी रूप से (कुछ दिनों के लिए) मेल की दक्षता का त्याग करना पड़ा, स्टोर में अतिरिक्त 6 टेराबाइट के अतिरिक्त स्थान के लिए, मुख्य सेवाओं को लॉन्च करने के लिए, जिस पर कंपनी की आय निर्भर थी।
VMware से अंग्रेजी बोलने वाले सहयोगियों के साथ हजारों चैट लाइनों को "मेमोरी के लिए" सहेजा गया था, यहां उनकी बातचीत के कुछ अंश हैं:

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

यह समस्या स्वयं कैसे प्रकट हुई (दृढ़ता से गिरी हुई संगठन सेवाओं के अतिरिक्त)।

एचबीए मोड में डिस्क के साथ डेटा एक्सचेंज के दौरान चेकसम त्रुटियों (सीआरसी) "नीले रंग से बाहर" की घातीय वृद्धि। इसे कैसे जांचें - प्रत्येक 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

निष्पादन के परिणामस्वरूप, आप इस नोड के vSAN क्लस्टर में प्रत्येक डिस्क के लिए CRC त्रुटियों को देख सकते हैं (शून्य मान प्रदर्शित नहीं किया जाएगा)। यदि आपके पास सकारात्मक मूल्य हैं, और इसके अलावा, वे लगातार बढ़ रहे हैं, तो मॉनिटर में लगातार उत्पन्न होने वाले कार्यों का एक कारण है -> vSAN -> क्लस्टर के ऑब्जेक्ट्स को पुनर्जीवित करना।

मानक तरीकों से क्लोन या माइग्रेट न करने वाली आभासी मशीनों के डिस्क को कैसे पुनर्प्राप्त करें?

शक्तिशाली बिल्ली आदेश का उपयोग करने के बारे में किसने सोचा होगा:

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]

कैसे पहचानें naa.xxxx ... डिस्क समूह में डिस्क:

[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

प्रत्येक ना के लिए vUAN UUIDs का पता कैसे लगाएं ....:

[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

और सबसे महत्वपूर्ण बात।

समस्या RAID नियंत्रक के फर्मवेयर के गलत संचालन और vSAN के साथ HPE ड्राइवर के रूप में निकली।
इससे पहले, VMware 6.7 U1 में, HPE स्मार्ट ऐरे P816i के लिए संगत फर्मवेयर vSAN HCL में SR Gen10 कंट्रोलर का संस्करण 1.98 था (जो हमारे संगठन के लिए घातक साबित हुआ), और अब यह #65 कहता है ।
इसके अलावा, संस्करण १.९९, जो उस समय (३१ जनवरी, २०१ ९) को समस्या को हल करता था, पहले से ही एचपीई के डिब्बे में था, लेकिन उन्होंने हमारे अस्वीकरणों के बावजूद प्रमाण पत्र की कमी का जिक्र करते हुए इसे या तो वीएमवेयर या हमें पास नहीं किया। , वे कहते हैं, हमारे लिए मुख्य बात यह है कि भंडारण के साथ समस्या को हल करना है और यही है।

नतीजतन, समस्या केवल तीन महीनों के बाद ही हल हो गई थी, जब डिस्क नियंत्रक के लिए फर्मवेयर संस्करण 1.99 जारी किया गया था!

मैंने क्या निष्कर्ष निकाले हैं?

( ), .
! .
«» , «» «» , 30% «».
HPE, , .
, :
- HPE - . , Enterprise . , , ).
- मैंने ऐसी स्थिति की उम्मीद नहीं की, जहां आपातकाल के मामले में कंपनी के सभी सर्वरों की प्रतियां लगाने के लिए अतिरिक्त डिस्क स्थान की आवश्यकता हो।
इसके अतिरिक्त, जो कुछ हुआ है, उसके प्रकाश में, वीएमवेयर के लिए मैं अब बड़ी कंपनियों, डेल के अलावा किसी भी विक्रेता के लिए हार्डवेयर नहीं खरीदूंगा। क्यों, क्योंकि DELL, जहां तक मुझे पता है, VMware का अधिग्रहण किया है, और अब इस दिशा में हार्डवेयर और सॉफ्टवेयर का एकीकरण यथासंभव संभव है।

जैसा कि वे कहते हैं, दूध में जला दिया, पानी में उड़ा।

वह सब लोग हैं। मैं चाहता हूं कि आप ऐसी भयानक परिस्थितियों में कभी न आएं।

जैसा कि मुझे याद है, मैं पहले से ही शुरुआत करूंगा!

VMware vSAN 6.7 - और गड़गड़ाहट हुई

More articles: