VMware vSAN 6.7 - وضرب الرعد

انتهى عام 2018 ...

مرة واحدة ، في يوم واضح من شهر ديسمبر ، قررت شركتنا شراء جهاز جديد. لا ، بالطبع ، هذا لم يحدث بين عشية وضحاها. تم اتخاذ القرار في وقت سابق. قبل ذلك بكثير. ولكن ، كالعادة ، لا تتزامن رغباتنا دائمًا مع قدرات المساهمين. ولم يكن هناك مال ، وتمسكنا به. ولكن في النهاية ، جاءت تلك اللحظة السعيدة عندما تمت الموافقة على الاستحواذ على جميع المستويات. كل شيء على ما يرام ، وصفق العاملون بفرح شديد ، سئموا من معالجة الوثائق لمدة 25 ساعة شهريًا على الخوادم التي يبلغ عمرها 7 سنوات ، وطالبوا بشدة قسم تكنولوجيا المعلومات بالخروج بشيء لمنحهم المزيد من الوقت لأشياء أخرى بنفس القدر من الأهمية .

لقد وعدنا بتقليل وقت معالجة المستندات 3 مرات ، حتى 8 ساعات. لهذا ، تم إطلاق عصفور من مدفع. بدا هذا الخيار هو الخيار الوحيد ، نظرًا لأن فريقنا لم يكن لديه ، ولم يكن لديه مطلقًا ، مسؤول قاعدة بيانات لتطبيق جميع أنواع تحسين الاستعلام (DBA).

كان تكوين المعدات المختارة ، بالطبع ، على ارتفاع عالٍ. كانت هذه ثلاثة خوادم من شركة HPE - DL560 Gen10. يضم كل منهم 4 معالجات Intel Xeon Platinum 8164 2.0Ghz مع 26 نواة و 256 DDR4 RAM و 8 SSD 800Gb SAS (800Gb WD Ultrastar DC SS530 WUSTR6480ASS204 SSD) + 8 1.92Tb SSD (Western Digital Ultrastar DC SS530 )

كانت هذه "القطع الحديدية" مخصصة لمجموعة VMware (HA + DRS + vSAN). التي تعمل معنا منذ ما يقرب من 3 سنوات على خوادم مماثلة من الجيل السابع والثامن ، أيضًا من HPE. بالمناسبة ، لم تكن هناك مشاكل حتى رفضت HPE دعمها وترقية ESXi من الإصدار 6.0 ، حتى إلى 6.5 ، بدون الدف. حسنًا ، نتيجة لذلك ، كان من الممكن التحديث. عن طريق تغيير صورة التثبيت ، إزالة وحدات المشكلة غير المتوافقة من صورة التثبيت ، إلخ. كما زاد هذا من نيران رغبتنا في مطابقة كل شيء جديد. بالطبع ، إذا لم يكن ل "حيل" vSAN الجديدة ، رأينا في التابوت تحديثًا للنظام بالكامل من الإصدار 6.0 إلى أحدث ، ولن تكون هناك حاجة لكتابة مقال ، لكننا لا نبحث عن طرق سهلة ...

لذا ، قمنا بشراء هذه المعدات وقررنا استبدال المعدات القديمة التي عفا عليها الزمن. قمنا بتطبيق SPP الأخير على كل خادم جديد ، تم تثبيته في كل منهما بطاقتي شبكة Ethernet 10G (واحدة لشبكات المستخدم والثانية لشبكة SAN ، 656596-B21 HP Ethernet 10Gb 2-port 530T). نعم ، جاء كل خادم جديد مزودًا ببطاقة شبكة SFP + بدون وحدات ، ولكن البنية التحتية لشبكتنا تتضمن Ethernet (مجموعتان من محولات DELL 4032N لشبكات LAN و SAN) ، ولم يكن لدى موزع HP في موسكو وحدات HPE 813874-B21 ونحن لم ينتظروا.

عندما حان الوقت لتثبيت ESXi ودمج العقد الجديدة في مركز بيانات VMware الشائع ، حدثت "معجزة". كما اتضح ، فإن HPE ESXi Custom ISO الإصدار 6.5 وما يليه غير مصمم ليتم تثبيته على خوادم Gen10 الجديدة. المتشددين فقط ، 6.7 فقط. وكان علينا أن نتبع تعليمات "الشركة الافتراضية" دون قصد.

تم إنشاء مجموعة HA + DRS جديدة ، وتم إنشاء مجموعة vSAN ، وكل ذلك بتوافق صارم مع VMware HCL وهذا المستند . تم تكوين كل شيء وفقًا لـ Feng Shui وكانت "الإنذارات" الدورية فقط مشبوهة في مراقبة vSAN حول قيم المعلمات غير الصفرية في هذا القسم:

صورة

لقد قمنا ، بكل راحة ، بنقل جميع الأجهزة الافتراضية (حوالي 50 قطعة) إلى خوادم جديدة وإلى تخزين vSAN جديد مبني على أقراص SSD ، قمنا بفحص أداء معالجة المستندات في البيئة الجديدة (بالمناسبة ، اتضح أنه يوفر الكثير من الوقت أكثر مما خططنا) . حتى تم نقل أكبر قاعدة إلى الكتلة الجديدة ، استغرقت العملية ، التي تم ذكرها في بداية المقالة ، حوالي 4 ساعات بدلاً من 25! كان هذا مساهمة كبيرة في مزاج العام الجديد لجميع المشاركين في العملية. ربما بدأ البعض يحلمون بجائزة. ثم غادر الجميع لحضور عطلة رأس السنة الجديدة.

عندما بدأت أيام الأسبوع من العام الجديد 2019 ، لم يكن هناك شيء كارثي. جميع الخدمات المنقولة إلى قدرات جديدة ، دون مبالغة ، انطلقت! أصبحت الأحداث في قسم إعادة المزامنة للكائنات فقط أكثر من ذلك بكثير. وبعد أسبوعين حدثت مشكلة. في الصباح الباكر ، توقفت جميع الخدمات الرئيسية للشركة تقريبًا (1s ، MSSQL ، SMB ، Exchange ، إلخ) عن الاستجابة ، أو بدأت في الاستجابة بتأخير طويل. سقطت البنية التحتية بأكملها في حالة من الفوضى الكاملة ، ولم يكن أحد يعرف ما حدث وماذا يفعل. جميع الأجهزة الافتراضية في vCenter بدت "خضراء" ، لم تكن هناك أخطاء في مراقبتها. لم يساعد إعادة التشغيل. علاوة على ذلك ، بعد إعادة التشغيل ، لم تتمكن بعض الأجهزة من التمهيد ، مما أدى إلى عرض أخطاء عملية مختلفة في وحدة التحكم. يبدو أن الجحيم جاء إلينا وكان الشيطان يفرك يديه تحسبًا.

تحت ضغط الضغط الشديد ، كان من الممكن تحديد مصدر الكارثة. تحولت هذه المشكلة إلى تخزين موزع vSAN. حدث تلف البيانات غير المنضبط على أقراص الجهاز الظاهري ، للوهلة الأولى - دون سبب. في ذلك الوقت ، كان الحل الوحيد الذي بدا عقلانيًا هو الاتصال بالدعم الفني لـ VMware مع الصراخ: SOS ، save-help!

وبالتالي ، أنقذ هذا القرار الشركة من فقدان البيانات ذات الصلة ، بما في ذلك صناديق بريد الموظفين وقواعد البيانات والملفات المشتركة. نتحدث معًا عن 30 تيرابايت من المعلومات.

إنه ملزم بالإشادة بموظفي دعم VMware الذين لم يقوموا بـ "كرة القدم" لمالك اشتراك الدعم الفني الأساسي ، ولكنهم أدرجوا هذه الحالة في قسم Enterpise ، وعملية التدوير على مدار الساعة.

ما حدث بعد ذلك:

  1. طرح الدعم الفني لـ VMware سؤالين رئيسيين: كيفية استرداد البيانات وكيفية حل مشكلة تلف البيانات "الوهمية" في أقراص الجهاز الظاهري في مجموعة القتال "vSAN". بالمناسبة ، لم يكن هناك مكان لاستعادة البيانات ، لأن التخزين الإضافي كان مشغولًا بنسخ احتياطية ولم يكن هناك مكان لنشر خدمات "قتالية".
  2. بينما حاولت ، مع VMware ، تجميع العناصر "التالفة" في مجموعة vSAN ، قام زملائي بتعدين مساحة تخزين جديدة يمكن أن تستوعب كل 30 تيرابايت من بيانات الشركة.
  3. , , VMware , , «» - - . , ?
  4. .
  5. , « » .
  6. , , «» .
  7. اضطررت بشكل مؤقت (لبضعة أيام) للتضحية بكفاءة البريد ، من أجل 6 تيرابايت إضافي من المساحة الحرة في المتجر ، لإطلاق الخدمات الرئيسية التي يعتمد عليها دخل الشركة.
  8. تم حفظ الآلاف من خطوط الدردشة مع الزملاء الناطقين باللغة الإنجليزية من 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

كيف تجلت هذه المشكلة (بالإضافة إلى خدمات المنظمة التي سقطت بشدة).

النمو المتسارع لأخطاء المجموع الاختباري (CRC) "خارج الحدود" أثناء تبادل البيانات مع الأقراص في وضع HBA. كيفية التحقق من ذلك - أدخل الأمر التالي في وحدة التحكم لكل عقدة 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

نتيجة للتنفيذ ، يمكنك رؤية أخطاء CRC لكل قرص في مجموعة vSAN لهذه العقدة (لن يتم عرض القيم الصفرية). إذا كانت لديك قيم إيجابية ، علاوة على ذلك ، فهي تنمو باستمرار ، فهناك سبب للمهام الناشئة باستمرار في الشاشة -> vSAN -> قسم كائنات Resincing من الكتلة.

كيفية استعادة أقراص الأجهزة الافتراضية التي لا تنسخ أو ترحل بالوسائل القياسية؟

من كان يظن باستخدام أمر القط القوي:

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

كيفية معرفة UUIDs لكل naa ....:

[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 وبرنامج تشغيل HPE مع vSAN.
سابقًا ، في برنامج VMware 6.7 U1 ، كان البرنامج الثابت المتوافق لوحدة تحكم HPE Smart Array P816i-a SR Gen10 في vSAN HCL هو الإصدار 1.98 (والذي تبين أنه قاتل لمنظمتنا) ، والآن يقول 1.65 .
علاوة على ذلك ، الإصدار 1.99 ، الذي حل المشكلة في ذلك الوقت (31 يناير 2019) ، كان بالفعل في صناديق HPE ، لكنهم لم يمرروه إلى VMware أو إلينا ، في إشارة إلى عدم وجود شهادة ، على الرغم من إخلاء المسؤولية لدينا وكل ذلك يقولون ، الشيء الرئيسي بالنسبة لنا هو حل مشكلة التخزين وهذا كل شيء.

ونتيجة لذلك ، تم حل المشكلة أخيرًا فقط بعد ثلاثة أشهر ، عندما تم إصدار إصدار البرنامج الثابت 1.99 لجهاز التحكم بالقرص!

ما هي الاستنتاجات التي خلصت إليها؟

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

    • HPE - . , Enterprise . , , ).
    • لم أتوقع موقفًا حيث قد تكون هناك حاجة إلى مساحة إضافية على القرص لوضع نسخ من جميع خوادم الشركة في حالة الطوارئ.
  6. بالإضافة إلى ذلك ، في ضوء ما حدث ، بالنسبة لـ VMware ، لن أشتري بعد الآن أجهزة للشركات الكبيرة ، أي بائعين بخلاف DELL. لماذا ، لأن DELL ، على حد علمي ، حصلت على VMware ، والآن من المتوقع أن يكون تكامل الأجهزة والبرامج في هذا الاتجاه قريبًا قدر الإمكان.

كما يقولون ، أحرقت في الحليب ، ضربة في الماء.

هذا كل شيء يا شباب. أتمنى ألا تدخل في مثل هذه المواقف الرهيبة.

على ما أذكر ، سوف أذهل بالفعل!

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


All Articles