Optane دیسک

دیسک های optane برخلاف SSD چیزی بنام Transistor ندارند به همین دلیل فرسوده شدن در این دیسکها معنی پیدا نمیکند و همین امر باعث افزایش Endurance دیسکهای optane خواهد شد . این دیسکها تقریبا برای اولین بار در سال 2017 توسط Intel معرفی گردیدند.

اما بد نیست نگاهی بیندازیم به تفاوت Optane و SSD  :

در SSD ، خواندن و نوشتن اطلاعات روی یک تعداد صفحه انجام میشود که این صفحات به مرور فرسوده میشوند و در نیتیجه نیاز است که اطلاعات برروی صفحات جدید نوشته شوند که ساخت و آماده نمودن این صفجات  جدید نیازمندیهای خود رادارد و همین انتقال اطلاعات به صفحات جدید باعث کاهش Performance خواهد شد ، حتی در SSD زمانیکه نیاز است تغییری برروی اطلاعات انجام گردد ابتدا باید اطلاعات از یک Page به Page دیگری منتقل گردند درصورتیکه در Optane تغییر اطلاعات در همان محل انجام میگردد  (یعنی چیزی به نام Page وجود ندارد که از تعدادی بلاک ساخته شده باشد  و مثلا جایی که نیاز به تغییر اطلاعات باشد یا اطلاعات جدید نیاز نیست روی Page جدیدی نوشته شوند و در همان جای موجود تغییرات انجام میگردد) و همین امر باعث افزایش Performance و Endurance در Optane ها خواهد شد . در تصویر زیر عکسی از  NAND SSD میبینیم که صفحات و فرسایش آنها به چه صورت است.

Optane ها به 2 صورت عرضه میگردند:
PCI  و U2  که در تصویر زیر میبینید .

P4800X اولین مدلی از Optane بود که وارد بازار شد و در سایزهای 375G , 750G , 1.5TB وجود دارد همانطور که در تصویر مشخص است برای استفاده از این مدل نیاز است که درگاه PCI  دستگاه X4 را نیز پشتیبانی کند . برخی از مشخصات P4800x در تصویر زیر مشخص شده:

مدل جدیدتر این دیسک که pci میباشد p5800 از نسل 4 است با ظرفیت های  400G , 800G , 1.6TB , 3.2
اما مدل دیگر که U2 نام دارد برای استفاده از این نوع مدل نیاز است که U2 backplane تهیه کنیم اما در صورتیکه این backplabe نداشتیم میتونیم از مبدل های زیر نیز استفاده کنیم

از مبدل های بالا میتوان گفت راحت ترین و کم دردسر ترین مبدل PCI to U.2 است که 2 عدد Optane را پشتیبانی میکند .
اما در Vmware کجا این دیسک ها میتوانند عملکر خود را نمایش دهند ؟ بهترین عملکرد را این دیسکها در هنگام پیاده سازی vSAN دارند . با توجه به endurance بالایی که دارند بهترین گزینه برای پیاده سازی vSAN به عنوان Cache tier  در حالت OSA میباشند . مدل P4800x توسط VMware  نیز تایید شده . ( برای پیاده سازی و استفاده در ESA تا به این لحظه توسط Vmware تایید نشده اند ) . لازم است بدانیم از optane ssd نمیتوانیم در ساختار Hybrid به عنوان cache استفاده کرد وتنها در ساختار All Flash امکان استفاده وجود دارد.

اشتراک گذاری در facebook
اشتراک گذاری در twitter
اشتراک گذاری در linkedin

قابلیتهای جدید vSphere 8

نسخه جدید vSphere8 منتشر شده و برخی ازقابلیتهای آن نیز که در VMware Explore معرفی گردید به شرح زیر میباشند:

1- DPU :

DPU یا همان Data Processing Unit   که در بخش vSphere distributed service engine  گنجانده شده،  استفاده اصلی از این تکنولوژی در Machine Learning است اما بیاید با هم کمی ببینیم چه قابلیتهایی به ما میدهد. DPU  در اصل یک device است که اصلاحا SmartNIC نامیده میشود به زبان ساده تر میتونیم شبیه یک کارت Network ببینیم که خودش شامل چندین بخش است. تصویر زیر را ببینید .

این Device که درحال حاظر تنها توسط 3 شرکت (Pensando)AMD , nvidia , intel  تولید میشود. این قطعه به تنهایی شامل CPU , Disk , Network , Memory میباشد و عملا روی خودش میتونیم esxi  نصب کنیم  این SmartNic شامل 2 تا پورت شبکه یا بیشتر هست که حداقل سرعت 10G و حداکثر 100G فراهم میکند (بسته به نوع کمپانی متفاوت است) و یک Port مدیریتی مجزا دارد (میشه بگیم معادل ILO مربوط به سرور)   عکس زیر نمونه ای از یک مدل DPU میباشد :

اگر DPU روی سرور داشته باشیم زمان نصب ESXi به صورت اتوماتیک توسط سیستم شناسایی میشود و میتوانیم محل نصب Esxi را این device انتخاب کنیم  نکته ای که خودVMware  درمستندات اشاره کرده این است زمانیکه  از DPU استفاده میکنید مقدار 20 % از بار روی CPU کاسته میشود . از دیگر مزایای استفاده از DPU میتوان به داشتن Low latency و امنیت بالاتر اشاره کرد.

2- بهبود فرآیند Recovery برای vCSA :

فرض کنید سه شنبه از vCenter یک backup تهیه کرده ایم حالا جمعه مشکلی ایجاد میشود در vCenter و نیاز به بازیابی داریم اما در روز پنجشنبه یک ESXi جدید به کلاستر ایجاد کردیم به همراه تغییرات دیگر پس قاعدتا این تغییرات درنسخه جدید vCenter که بازیابی شده موجود نمیباشد حالا چاره چی هست ؟ در vSphere8 یک قابلیت جدید گنجانده شده برای این زمان . وضعیت کلاستر در ESXi  ها به صورت یک DKVS (Distributed key value store) ذخیره میگردد به زبان ساده تر میشه گفت تمامی

تغییرات ، مشابه یک فایل در DKVS ذخیره میشوند همانطور که از اسمش مشخص هست این DKVS یه صورت توزیع شده روی تمامی هاستها وجود دارد و عملا اطلاعات بین کلاستر و هاستها Sync میشوند. حالا که vCenter بازیابی میگردد تمامی تغییرات با توجه به اینکه در DKVS  ذخیره شده بودند با اضافه نمودن هاستها به کلاستر مجددا بازیابی میگردند. و vCenter بروز میگردد.
درنظر داشته باشید همانطور که VMware چندین بار اعلام کرده این روش به عنوان راهکار جایگزین نمیباشد و تنها یک روش بهبود یافته در زمان بازیابی vCenter میباشد .در تصویر زیر میتونه به درک DKVS کمک بیشتری نماید.

3- بهبود vLCM :

در آن واحد امکان بروز رسانی چندین هاست همزمان به کمک vLCM  فراهم شده ( حداکثر 10 هاست تا این لحظه ) که البته این قابلیت مناسب سایتهایی میباشد که تعداد هاست بالایی دارند و نیاز به بروزرسانی در کمترین زمان را دارند.

فرآیند Stage نیز به vLCM اضافه شد که باعت میشه هاست مدت بیشتری در دسترس باشد و از طرفی DownTime کاهش میابد (عملا قبل از اینکه هاست در حالت Maintenance mode قرار بگیره عملیات Stage انجام میگردد)

4- Device group:

به این صورت کار میکند که میتونیم به صورت Logical چندین device مانند GPU و NIC به یکدیگر لینک کنیم و همه در قالب یک Device group به یک ماشین متصل شوند.
این قابلیت بیشتر برای جاهایی استفاده میشود که دارای GPU میباشند مثلا در Machine Learning.
درحال حاظر به سرورهای فیریکی میتوان 8 تا GPU اضافه کرد و روی بعضی از سرورها تا بیشتر از 8 تا هم پشتیبانی میکند اما درنسخه 8 به هر VM حداکثر میتوانیم 8 تا vGPU بدهیم . حالا همین 8  عدد vGPU را  میتوانیم به صورت مستقیم به ماشین بدهیم ( نه از طریق روش Passthrough)  چون از طریق Device Group  کنترل بیشتری روی VM داریم و مییتوانیم مواردی مثل vMotion داشته باشیم . درنتیجه با توجه به قابلیت Device group که جلوتر بیشتر توضیح میدیم میتونیم چندین GPU به صورت dedicate همزمان به یک ماشین اختصاص بدهیم. عملا الان اگر ماشین به 2 عدد GPU نیاز داشته باشد دو راه وجود دارد که به ماشین assign کنیم یا 2 تا pci device  مستقیم همانند سابق به VM میدهیم ( مشکل این روش این هست که با این مدل دردسر پیکربندی داریم چون باید از اون طرف بریم داخل os و درایورهای لازم نصب کنیم و کلی کار دیگه که بتونه تشخیص بده این 2 تا GPU یک جورایی با هم حالت Team شده اند اما روش دوم که همین device group است عملا 2 تا کارت انتخاب میکنیم بدون اینکه passsthrough کنیم و هر 2 در یک گروه قرار میگیرند و به ماشین اضافه میشوند و تمام تنظیمات انجام میگردد به صورت اتوماتیک  و NVLI NK نیز به خوبی برقرار میگردد بین کارتهای GPU و روش اضافه کردن هم همانند سابق روی گزینه pci device میزنیم .

5- VTPM:

برای اضافه کردن آن روی ماشین به هیج قطعه سخت افزاری نیاز نداریم .
روی ماشین راست کلیک کرده و گزینه Trusted platform module میزنیم . در کل vtpm اطلاعاتی که encrypt میکند میتواند شامل کلیدها و پسوردها و همچنین کلید که برای backup گیری استفاده میشوداما بد نیست برخی از مشکلاتی که vtpm برای ما ممکن است ایجاد نمایید ذکرکنیم :

برای راه ادازی VTPM باید یک key provider  ایتدا در محیط ایجاد کنیم .
ماشین که دارای VTPM است نمیتوان از آن export ovf/ova بگیریم .
ماشین که دارای VTPM است فقط home file رمزگذاری میشود .
ماشین که دارای VTPM است حتما باید EFI باشد.
ماشین که دارای VTPM است اگر بخواهیم device به آن اضافه کنیم باید حتما ماشین خاموش شود چون نیاز هست اون تغییر در فایل vmx قرار بگیرد و نیاز هست این فایل مجدد encrypt شود.

اما قابلیتی که درنسخه 8 اضافه شده امکان Replace و یا کپی کردن vtpm در هنگام CLONE گرفتن از ماشین است همانند تصویر زیر:

اشتراک گذاری در facebook
اشتراک گذاری در twitter
اشتراک گذاری در linkedin

رفع مشکل نصب ESXi به دلیل UUID یکسان

گاهی پیش میاد هنگام نصب نسخه Esxi با پیغامی زیر روبرو میشویم پیغامی مبنی بر اینکه نسخه ای از Esxi از قبل روی سیستم نصب میباشد و امکان نصب مجدد نیست

 حتی ممکن هست با تغییر Raid دیسکها این پیغام از بین نرود . اما برا رفع مشکل مراحل زیر را انجام میدهیم :

هنگام boot شدن Esxi در زمان نصب مانند تصویر زیر کلیدهای Shift+o را میزنیم  و عبارت overrideDuplicateImageDetection را تایپ میکنیم و کلید Enter را میزنیم

حالا مراحل نصب آغاز میشود اما بجای نصب در همین مرحله اول قبل از انتخاب دیسک محل نصب وارد محیط shell میشویم به کمک کلیدهای Alt+F1 حالا در اینجا نیاز هست که ادرس دیسکها را پیدا کنیم  :

ls/vmfs/devices/disks

همانطور که درتصویر بالامشخص است اسامی دیسکها به همراه Partition Number که در تصویر عدد 9 میباشد مشخص شده حالا نوبت به Format نمودن دیسکها میرسد :

partedutil delete /vmfs/devices/disks/naa.600508b1001cc630d5dbfa3924c052674c4f47494341  9

و در نهایت بعد از پاک کردن دیسکهای مورد نظر با فشردن Alt+F2 از این محیط خارج میشویم و ادامه فرآیند نصب را انجام میدهیم.

اشتراک گذاری در facebook
اشتراک گذاری در twitter
اشتراک گذاری در linkedin

بروزرسانی ESXi از طریق Ansible

خیلی از ما علاقه به بخش CLI داریم ودوست داریم برخی از کارها  را از طریق خط فرمان انجام دهیم یکی از این موارد بروز رسانی ESXi از طریق Ansible هست .  
درنظر داشته باشید من تمام بخشها و فولدرهای مربوط به Ansible حذف کردم و تمامی کامندها در همون update.yml مینویسیم .

اما برای run شدن playbook باتوجه به اینکه هیچ کلیدی نمیسازیم و در نتیجه کلیدی منتقل نمیکنیم به سرورهای ESXi  باید key_checking غیرفعال گردد. چون فقط برای هاستهای ESXi نیاز هست که key checking غیرفعال باشه درنتیجه زمان اجرای Play book  این تغییر را اعمال میکنیم .  (Playbook از اینجا میتونید دریافت کنید)

ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook /etc/ansible/repo/update.yml –vvv –ask-pass

Ask-pass برای دریافت کلمه عبور ESXi  استفاده میشود( کلمه عبور تمامی ESXi ها باید مشابه هم باشد یک بار که کلمه عبور وارد شود تغییرات روی تمامی هاستهای دیگر هم نیز اعمال میشود.)

بعد از وارد نمودن کلمه عبور مراحل اعمال تغییرات همانند تصاویر زیر شروع میشود.

همانطور که درتصویر بالا مشخص است عملیات بروزرسانی با موفقیت انجام شده و در نهایت در تصویر زیر عملیات Ansible با موفقیت انجام شده که تعداد Change نشاندهنده این مورد میباشد. در آخر بعد از اعمال تغییرات همانند قبل ، با راه اندازی مجدد ESXi تغییرات اعمال خواهند شد.

اشتراک گذاری در facebook
اشتراک گذاری در twitter
اشتراک گذاری در linkedin

بررسی و رفع مشکل vCLS

ممکنه برای شما هم پیش امده باشه که ماشینهای مربوط به vCLS به مشکل خوردند و یا وقتی روی آنها کلیک میکنیم در بخش Summary خطا مشاهده کنیم . یکی از راهکارها  غیرفعال و مجددا فعال نمودن vCLS در سطح کلاستر میباشد که اصطلاحا Retreat Mode نام دارد که شامل مراحل زیر است :

درابتدا بعد از Login به vcenter نیاز است ID مربوط به کلاستر مشخص گردد :

کلاستر مربوطه را انتخاب میکنیم و همانند عکس زیر cluster ID  را پیدا میکننیم ( در اینجا c40 مقدار Cluster ID میباشد)

 سپس vCenter را انتخاب میکنیم و به بخش Configure میرویم درصفحه باز شده به بخش Advanced settings میرویم سپس Edit settings راانتخاب میکنیم و خط زیر را اضافه میکنیم

Name : config.vcls.clusters.domain-c40.enabled
Value : false

بعد از اعمال تغییرات و ذخیره نمودن ماشینهای مربوطه به vCLS همگی پاک میشوند و مجددا مراحل بالا را تکرار میکنیم و این بار مقدار config.vcls.clusters.domain-c40.enabled را به true تغییر میدهیم و مجددا عملیات Provisioning مربوط به vCLS شروع  میشود.

نکته :

1- این مراحل فقط برای انجام troubleshoot باید انجام شود و به هیچ عنوان vCLS را disable نکنید.

2- در زمان Disable نمودن vCLS فرآیندهای DRS , HA در سطح کلاستر کاملا غیرفعال خواهند شد ( به عنوان مثال در این لحظه در صورت انجام maintenance mode هیچگونه عملیات Migrate به صورتی اتوماتیک انجام نخواهد شد)

اشتراک گذاری در facebook
اشتراک گذاری در twitter
اشتراک گذاری در linkedin

چگونگی تست Network Adapter برروی ESXi

یکی از بهترین روش ها برای تست Performance کارت شبکه استفاده از ابزار iperf هست در این روش تنها مبدا و مقصد  مشخص میشوند و در نهایت شروع به ارسال داده میشود و عملکرد Physical Adapter به خوبی مشخص میگردد.

خوشبختانه بسته  iperf از نسخه 6.5 به صورت پیش فرض برروی ESXi قرارگرفته است (تست network performance که در vSAN انجام  میشود از همین ابزار استفاده میکند) که در مسیر زیر قرار گرفته :

usr/lib/vmware/vsan/bin/iperf3/

اما برای شروع تست مراحل زیر را انجام میدهیم .
فرض کنیم ip  سرور اول = 10.20.20.20  و ip  سرور دوم = 10.20.20.40  میباشد .
ابتدا 2 سرور مورد نظر را انتخاب میکنیم (روی هاست اول iperf به عنوان سرور عمل میکند و روی هاست دوم iperf به عنوان Client )

روی هاست اول ابتدا از فایل iperf3 باید یک نسخه کپی تهیه کنیم ( زمانیکه میخواهیم iperf در نقش server عمل کند باید حتما یک کپی قبل از اجرا بگیریم و همان فایل کپی را اجرا کنیم درغیر این صورت با پیغام Operation not permitted روبرو خواهیم شد (

سرور اول (iperf as server) :

cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

/usr/lib/vmware/vsan/bin/iperf3.copy -s -B 10.20.20.20

  -s: یعنی iperf در نقش سرور روی این هاست اجرا شود
  -B:  مشخص کننده IP که iperf برروی آن Listen انجام میدهد

سرور دوم (iperf as client) :

usr/lib/vmware/vsan/bin/iperf3 -i 1 -t 20 -c 10.20.20.20 -fm/

-i : تعداد فواصلی که بسته ارسال میشود (Interval)
-t : تعداد بسته هایی که ارسال میکند
-fm : ازآنجاییکه خروجی به صورت پیش فرض kbit/s است و کمی خواندن (برای من به شخصه ) سخت هست از این سوییچ استفاده میکنیم که mbit/s باشد.

و در نهایت خروجی زیر نمایش داده میشود ( همانطور که مشاهده میکنید 21.8GB دیتا منتقل شده با پهنای باند تقریبا 10 Gbits/sec.

نکته : قبل از اتجام تست ، هم سمت server و هم سمت Client توصیه میشود Firewall غیر فعال گردد :

esxcli network firewall set –enabled false

و بعد از انجام تست مجددا فعال شود.

esxcli network firewall set –enabled true

اشتراک گذاری در facebook
اشتراک گذاری در twitter
اشتراک گذاری در linkedin

چگونه یک ContentLibrary را از دیتابیس VCSA حذف کنیم

ممکنه با این مشکل مواجه شده باشید که نیاز به حذف ContentLibrary باشد اما از داخل vCenter امکان حذف وجود ندارد در این مرحله تنها راهکار حذف Object از طریق دیتابیس میباشد.

ابتدا از  طریق فرمان زیر به دیتابیس متصل میشویم .

opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres/

سپس از طریق پرسمان زیر یک لیست از ContentLibrary ها به همراه ID میگیریم:

VCDB=# select id,name from cl_library;

                  id                  |     name
————————————–+—————
 061c30a2-be31-487a-b0f3-404e7264d42d | LabContentDS1
 d8f7c5d-c926-49c9-b23b-b2858465bff5   | content20

(2 rows)

دراین مرحله Id مربوطه به Storage که ContentLibrary برروی آن است مشخص میکنیم :

VCDB=# select * from cl_library_storage;

              library_id              |              storage_id
————————————–+————————————–
 c30a2-be31-487a-b0f3-404e7264d42d | 25b6107b-7bb6-450e-9776-54520f65b1e2061
 0d8f7c5d-c926-49c9-b23b-b2858465bff5   | 6fa822a2-2cba-44ef-a5bd-6b7812e2c234

(2 rows)

در اینجا میخواهیم storageui مربوط به Datastore را پیدا کنیم تا به کمک آن درمرحله بعد نام Datastore مشخص گردد:

VCDB=# select * from cl_storage;

در این مرحله نام Datastore مشخص میگردد :

VCDB=# select id,name from vpx_datastore where id=744

id  |         name
—–+———————-
 744 | Lab-Storage

(1 row)

اکنون با توجه به اطلاعاتی که بدست آوریم نوبیت به حذف رکوردها از دیتابیس و درنهایت حذف ContentLibrary :

VCDB=# delete from cl_library_storage where library_id=’0d8f7c5d-c926-49c9-b23b-b2858465bff5’;

DELETE 1

VCDB=# delete from cl_storage where id=’6fa822a2-2cba-44ef-a5bd-6b7812e2c234’;

DELETE 1

VCDB=# delete from cl_library where id=’0d8f7c5d-c926-49c9-b23b-b2858465bff5’;

DELETE 1

اکنون بعد از Login به محیط vcsa در بخش Content library   میبینیم که حذف شده و یا اینکه مجددا همین جا میتونیم Select بگیریم و وضعیت ببینیم .

VCDB=# select id,name from cl_library;

                  id                  |     name
————————————–+—————
 c30a2-be31-487a-b0f3-404e7264d42d | LabContentDS1061

(1 row)

اشتراک گذاری در facebook
اشتراک گذاری در twitter
اشتراک گذاری در linkedin

چگونگی بروزرسانی ESXi و vCenter به نسخه 7.0U3c و رفع مشکل Dual driver

بالاخره بعداز چند ماه بروزرسانی جدید  vSphere 7.0U3c (01/28/2022) منتشر شد اما قبل از انجام این بروزرسانی چند مورد باهم بررسی کنیم .

همانطور که میدانیم در فرآیند بروزرسانی ابتدا vCenter بروز میشود و سپس ESXi اما برای بروز رسانی به این نسخه موضوع برعکس هست !!!!!! . اما دلیل این امر چی هست ؟ برای اولین بار درنسخه ESXi 7.0u2 شرکت intel نام درایور خودرا از i40en به i40enu تغییر داد اما در نسخه 7.0u3 مجددا به نام قبلی بازگشت اما باتوجه به تغییر نام مجدد، ارتباط بین این 2 درایور به درستی ایجاد نگردید و هرکدام به صورت مجزا دربرروی سیستم فعال میباشند که موجب اختلالاتی در HA و NSX  میگردد اما برای رفع مشکل و بروز رسانی به نسخه جدید 2 راهکار پیشنهاد شده :

1- ابتدا فایل vSphere_upgrade_assessment.zip را دانلودمیکنیم و از حالت zip خارج کرده و سپس اسکریپت vSphere_upgrade_assessment.py را دانلود و برروی vCenter اجرا میکنیم:
(دراینجا اسکریپت در مسیر tmp/ سرور vcsa قرارمیدهیم.)

tmp/python vSphere_upgrade_assessment.py/

خروجی اسکریپت شامل 4 فایل میباشد که در همان مکانی که اسکریپت قرار دارد فایلها به تاریخ اجرا ایجاد میگردند:

vSphere_upgrade_assessment_skipped_hosts_YYYY-DD-MM.txt
vSphere_upgrade_assessment_errored_hosts_ YYYY-DD-MM.txt
vSphere_upgrade_assessment_faulty_hosts_ YYYY-DD-MM.txt
vSphere_upgrade_assessment_ YYYY-DD-MM.log

vSphere_upgrade_assessment_skipped_hosts_YYYY-DD-MM.txt:
شامل اسامی هاستهایی میباشد که در زمان اجرای اسکریپت در وضعیت Disconnect بودند.

vSphere_upgrade_assessment_errored_hosts_ YYYY-DD-MM.txt:
شامل اسامی هاستهایی میباشد که به دلایلی پاسخی به اسکریپت اجرا شده نداده اند که حتما باید یک بار ریستارت شوند و مجددا اسکریپت اجرا گردد.

vSphere_upgrade_assessment_faulty_hosts_ YYYY-DD-MM.txt
میشه گفت فایل اصلی همین فایل است در این فایل اسامی هاستهایی نمایش داده میشود که هر 2 درایور برروی آنها نصب شده است (اصطلاحا dual driver) و برای بروزرسانی vCenter ابتدا این هاستها باید update شوند و سپس vCenter .

نکته : برای بروز رسانی ESXi در اینجا حتما باید از ISO استفاده کنیم .

اما راه حل دوم :

ابتدا چک میکنیم که آیا درایور i40enu وجود دارد یا خیر :

در مرحله بعد میتونیم به صورت دستی درایور i40enu ازروی هاست به کمک فرمان زیرپاک کنیم و هاست را مجددا راه اندازی کنیم .

esxcli software vib remove –vibname=i40enu

بعد از بالا آمدن کامل هاست ، مانند قبل ابتدا vcsa را بروزرسانی میکنیم به اخرین نسخه و پس از آن بروز رسانی Esxi.

درنهایت اگر از نسخه VMware ESXi 7.0.2  با build-17867351 به قبل استفاده کنیم نیاز به انجام این مراحل نیست و همانند سابق امکان بروز رسانی ESXi و vCenter وجود دارد.

اشتراک گذاری در facebook
اشتراک گذاری در twitter
اشتراک گذاری در linkedin

دراینجا میخواهیم درمورد Encryption در vSAN صحبت کنیم . به طور کلی در vSAN دو نوع Encryption وجود دارد :

• vSAN Data at Rest Encryption
• vSAN Data in Transit Encryption

در ابتدا مورد اول بررسی میکنیم (vSAN Data at Rest Encryption):

این نوع از Encryption به گونه ای عمل میکند که زمانی اطلاعات برروی دیسک قرار گرفتند Encrypt میشوند و هیچ ارتباطی به نوع Policy که میسازیم ندارد به گونه ای که اطلاعا ت هم در Cache- Tier و هم در capacity – Tier به صورت Encrypt  قرار میگیرند و حتی زمانیکه از قابلیتهای D&C نیز استفاده میکنیم فرآیند Encryption به خوبی انجام میگردد. ضمنا برای انجام این نوع Encryption احتیاج به یک KMS میباشد.  درصورتیکه روز اول فعال نشده باشد برای فعال شدن نیاز است تمامی اطلاعات Disk Group حذف شود.

مورد دوم (vSAN Data in Transit Encryption):

همانطور که از اسم مشخص است در این حالت Encryption بین 2 هاست مبدا و مقصد انجام میشود در مدل قبل میشه گفت اطلاعت وقتی روی دیسک قرار میگرفتند Encrypt  میشد و اگر شخصی دیسک خارج میکرد تمام اطلاعات رمزگذاری شده بودند اما در این نوع فقط اطلاعاتی که بین هاستها از طریق Network ارسال میشوند Encrypt  میباشند و هیچ ارتباطی به اطلاعات روی دیسک ندارد. برخلاف مدل قبل در این حالت نیاز به سرور KMS نیست و کلیدها به صورت داخلی ساخته میشوند. فرآیند ایجاد کلید در این مدل به صورت زمانبندی شده میباشد و به صورت پیش قرض هفتگی است که قابل تنظیم است .

در زیر جدولی ازتقاوت این 2 مدل نیز قرار دارد :

در انتها نکاتی پیرامون فعال کردن Encryption:

برای فعال کردن Encryption نیاز به لایسنس vSAN Enterprise  یا vSAN Enterprise plus  میباشد.

درصورتیکه اطلاعات زیادی برروی vSAN داریم فعال کردن این مورد در ابتدا کاهش چشم گیری بر عملکرد vSAN خواهد گذاشت.

توصیه میشه درصورتیکه میخواهید Encryption  ازنوع Data at Rest فعال کنید توصیه میشود حتما این کار قبل از قرار گرفتن vSAN در محیط Production صورت گیرد.

اشتراک گذاری در facebook
اشتراک گذاری در twitter
اشتراک گذاری در linkedin

ESXi 7.0 و SD-Card

مسلما بسیاری از ما  به  دلیل کاهش هزینه ترجیح میدهیم  ESXi  را روی SD-Card و یا USB device نصب کنیم ، اما همانطور که میدانید با انتشار نسخه 7 تغییراتی در ساختار ESXi بوجود آمد . اما آیا این تغییرات باعث ایجاد محدودیت در فرآیند نصب و Boot شدن ESXi از روی device هایی مانند USB , SD-Card میشوند ؟
قبل از هرچیز شاید بهتر باشد نگاهی کوتاهی به ساختار ESXi درنسخه های پیش از 7 بیندازیم :

در نسخه های پیشین سایز پارتیشنها ثابت بود . همین محدودیت سایز پارتیشن باعث میشد زمانیکه از چندین محصول دیگر VMware مانند vSAN , NSX , Tanzu به صورت همزمان میخواهیم استفاده کنیم و جایی نیاز به فعال کردن بعضی Module های سنگین میباشد اختلالاتی ایجاد شود. همین افزایش نیاز به استفاده از چنین راهکارهایی باعث تغییراتی در ساختار ذخیره سازی خود ESXi شد. همانطور که در تصویر زیر دیده میشود درنسخه 7 برخلاف نسخه های پیشین ظرفیت تمامی پارتیشنها به حالت Dynamic تغییر کرده و تنها پارتیشن boot درحالت static است و 100MB فضا دارد.

از آنجاییکه درنسخه 7  تعداد درخواستهای ارسالی به ESX-OSDAT  به طور قابل چشمگیری افزایش پیدا کرده و با توجه به اینکه USB device و یا SD-Card توانایی تحمل این حجم از IO را ندارد توصیه شده که از Persistent disk استفاده شود. تعدادی از این درخواستها به شرح ذیل است :

1- افزایش تعداد درخواست بررسی وضعیت دیسک که ESXi برروی آن نصب شده .
2- افزایش تعداد دفعات Backup گیری هایی که درداخل سیستم به صورت پیش فرض زمان بندی شده اند (به طور مثال Backup گیری که به صورت خودکار ازتنظیمات ESXi گرفته میشه )
3- قرارگرفتن VMTools برروی ESX-OSDATA که چنانچه درخواستهای زیادی برای نصب VMwae Tools ارسال گردد باعث مشکل در SD-Card یا USB device  میشود (البته این مشکل در نسخه 7.0 U2C ازطریق انتقال این مسیر برروی RAM مرتفع گردیده)
4- همچنین بسیاری از Solution ها مانند NSX , vSAN , Tanzu تعدادی از لاگها و تنظیمات در این مسیر قرار میدهند.

درتصویر زیر اطلاعاتی که در پارتیشن ESX- OSDATA قرار میگیرند نمایش داده شده .

اما محدودیتهایی که درصورت وجود SD – card  یا USB device وجود دارد :

همانطور که درتصویر بالا مشخص است فضای ESX-OSDATA یکی ازفضاهای مهم میباشد اما از نسخه 7.0 U3 امکان قرار گرفتن پارتیشن ESX-OSDATA برروی SD card وجود ندارد .
از نسخه 7.0U3 به بعد ظرفیت SD card و یا USB device حداقل باید 8 گیگ باشد (که از این فضا فقط به عنوان Boot میتوان استفاده کرد  System boot برروی این بخش قرار میگیرد) و درکنار آن باید یک دیسک Local برروی سرور وجود داشته باشد به منظور قرار گرفتن فضا ESX-OSDATA.

اگر از SD Card استفاده کنیم و هیچگونه Persistent disk نداشته باشیم فضای /tmp با حجم 250MB برروی فضای Memory ساخته میشود و اگر این فضا پر شود باعث ایجاد کندی در ESXi میشود.

مسلما تعداد زیادی از افراد از SD card مربوط به HPE (Dual SD card) استفاده میکنند . تمامی این موارد و مشکلات برروی این مدل هم نیز وجود دارد .

درنهایت راه حل های جایگزین برای رفع این مشکل در جدول زیر نمایش داده شده :

همانطور که در تصویر مشخض است بهترین راه حل با خط قرمز مشخص شده . در این حالت پیشنهاد اسفاده از دیسکهای Local میباشد ( نصب ESXi برروی دیسکهای M2 , SSD  و با Boot From SAN ) میباشد .

نکته آخر : در وهله اول سعی کنید درصورتیکه از نسخه 7 به بعد استفاده میکنید به هیچ عنوان ESXi برروی SD Card و USB device نصب نکنبد چون حتما با خرابی های پی در پی برروی SD Card مواجه خواهید شد. و چنانجه هیچ راهکار دیگری جز استفاده از SD Card ندارید حداقل ظرفیت SD Card که استفاده میکنید 8 گیگ باشد و در کنار آن از یک دیسک لوکال با ظرفیت حداقل 32 گیگ نیز استفاده کنید به منظور قراردادن فضای ESX – OSDATA.

اشتراک گذاری در facebook
اشتراک گذاری در twitter
اشتراک گذاری در linkedin