آیا میشه از ESXi و کانفیگش یک Backup Image گرفت؟

ای سوالی بود که همیشه سر کلاس بچه ها از من میپرسیدن و من می گفتم هیچوقت نیاز به هنچین کاری نداری.

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

زمانی که هاستی خراب میشه باید ESXi جدید روش نصب کنی و با استفاده از Host Profile کانفیگ رو برگردونی.

این عملکرد به خاطر این هستش باید هاست رو مانند بقیه ها هاست ها کانفیگ تا بتونه درست کار کنه.

اما هفته پیش یک سناریو برای خودم پیش اومد که مجبور شدم از ESXi یک Backup Image بگیرم;

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

سناریوی من برای گرفتن Backup Image از ESXi

بر روی یک سرور لابراتوار 5 تا هارد داشتم که اونها رو Raid 5 کرده بودم;

به عنوان تنها دیتا استور برای محیط مجازی سازی از اون داشتم استفاه می کردم.

یک دفعه یک فلش بی کار تو خونه پیدا کردم و تصمیم گرفتم که ESXi رو بر روی اون نصب کنم.

به ذهنم خطور کرد که من کانفیگ پیچیده ای روی این سرور لابراتوار نزدم ولی واقعا انرژیش رو ندارم دوباره ESXi نصب کنم .

برای همین تصمیم گرفتم که سیستم عامل رو از روی هارد Local به روی USB جابجا کنم.

میدونم این کار برای من خطر نداره چون تا آخر عمر این همین یدونه هاست میمونه و بس.

این عملیات کار آسونیه ولی باید چند تا نکته ریز رو در نظر داشته باشید، که تو ادامه مطلب خواهید خوند.

مرحله اول پیدا کردن آدرس USB یا دیتا استوری که ESXi روی اون نصب شده

چون باید دستور Image گرفتن از داخل Shell یا SSH بزنید احتیاج دارید تا آدرس فعلی جایی که ESXi نصب شده رو پیدا کنید.

برای این منظور به سرور ESXi وصل شید ( Shell یا SSH) و از شاخه Dev/Disks آدرس USB یا هارد فعلی رو پیداکنید.

عکس زیر رو ببینید :

در 99 درصد موارد آدرس USB ها با آدرس MPX.VMHBA32 شروع میشن.

پس تو اینجا آدرس USB ای که ESXi روش نصبه : mpx.vmhba32:C0:T0:L0 هستش.

مرحله دوم کپی کردن کل USB در داخل یک فایل Image

برای کپی کردن باید از کامند dd استفاده کنید پس دستور پایین رو میزنیم :

dd if=/dev/disks/mpx.vmhba32:C0:T0:L0 of=/vmfs/volumes/SSD/esx1.img

با این کار یک فایل با نام esx1.img بر روی دیتا استور دومم که اسمش SSD هست ایجاد می کنه.

نکته : اگر دارید از روی هارد لوکالی Image میگیرید که حجمش زیاده بهتره با دستور gzip اینکار رو انجام بدید.

این کار باعث میشه که وقتی Image میگیره بلاک های 0 رو پاک کنه :

dd if=/dev/disks/mpx.vmhba32:C0:T0:L0 | gzip > /vmfs/volumes/SSD/esx1.img

مرحله سوم write کردن فایل بر روی USB مقصد

برای اینکار میتونید از داخل ESXi دستور زیر رو بزنید  :

dd if=esx1.img of=/dev/sdb

که /dev/sdb آدرس USB مقصد هستش.

یا از نرم افزار USBIT استفاده کنید.

دانلودش کنید و Image رو بهش بدید در نهایت دکمه Restore رو بزنید.

حالا هر وقت خواستید میتونید USB جدید رو بزنید و بدون هیچ تغییری از همون ESXi قبلیتون ولی ایندفعه از روی USB جدیده استفاده کنید.

NTP سرور داستان اصلی تمام ادمین هاییست که دارن تو صنعت IT کار میکنن.

اگر شما هم ادمین هستید صد در صد تا حالا 100 بار با این مشکل مواجه شدید و Time سیستم هاتون اذیتتون کرده.

تو این مطلب آموزشی یه راهی رو بهتون یاد میدم که برای همیشه از زحمت پیاده سازی یک NTP سرور خلاص شید.

تو این مطلب بهتون یاد میدم خود ESXi که در واقع NTP Client هستش رو تبدیل به NTP سرور کنید ;

و به همه بگید بیان تایمشون رو از روی ESXi ست بگیرند.

ادمین های مجازی سازی الان از خودشون میپرسن که این قابلیت تا حالا وجود داشته و من داشتم ازش استفاده می کرد!!!!؟؟؟

نه ما تا حالا از ESXi به عنوان NTP Client استفاده می کردیم و تایم رو از یک NTP سرور تحت شبکه میگرفتیم;

فقط این قابلیت رو داشتیم که با استفاده از یک تیک ( عکس زیر رو ببین) به ماشین های مجازی بگیم که Clock رو از روی ESXi بگیرن.

چیزی که من تو این مطلب بهتون یاد میدم اینه که به جای اون تیک، تایم رو از ESXi بر روی شبکه بگیرید دقیقا مثل NTP سرور واقعی.

مراحل تبدیل ESXi به NTP سرور

همونطوری که میدونید Kernel پلتفرم ESXi لینوکس هستش و مثل تمام Linux ها فایل NTP.Conf داره.

ما می خوایم روی این فایل یک تغییراتی ایجاد کنیم ، برای همین تو اولین کارمون یک بک آپ از این فایل میگیریم.

طریقه بک آپ گرفتن از اون هم اینه که به یک اسم دیگه تو همون دایرکتوریش کپی کنیم:

cp /etc/ntp.conf /etc/ntp.conf.bk

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

در داخل این فایل یک خط دستور هستش که کل مشکلات ما از این یک خطه. اونم Restrict شدن قابلیت NTP به ignore هستش.

با کامند “vi” فایل NTP.Conf رو باز می کنیم و این خط کامند رو Comment می کنیم.

این کار یعنی اینکه آقا این خط رو دیگه اعمال نکن.

درست مثل خط زیر :

#restrict default ignore

تو مرحله بعدی به ازای هر Subnet یا Network ای که قرار این NTP سرور رو ببین یک خط دستور وارد می کنید.

این خط دستور میگه که با اون Subnet یا Network مهربون باشه و بزاره باهاش ارتباط بگیرن.

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

بعد فایل رو ذخیره کنید و ببندیدش.

چجوری ذخیره کنم :

اول دکمه Scape رو بزنید بعد دو نقطه (:) رو بزنید و بعد دکمه W و بعد دکمه Q رو بزنید ( یعنی Write & Quite).

بعد Enter بزنید.

تا الان همه چی اوکیه و کارمون عالی بوده اما در ESxi هیچ سرویسی برای NTP سرور وجود نداره .

برای همین خودمون باید یک Custom Service بنویسید.

نگران نباشید من بهتون میگم چجوری و آسون هم هست.

برید به آدرس زیر :

/etc/vmware/firewall/

دستور زیر رو بزنید :

vi custom.xml

با این کار یک فایل به نام custom.xml ایجاد می کنه و برای ادیت هم بازش می کنه.

حالا محتویات زیر رو کپی کنید توی فایل :

<ConfigRoot>
<service id=’0045′>
<id>ntpServer</id>
<rule>
<direction>inbound</direction>
<protocol>udp</protocol>
<port type=’dst’>123</port>
</rule>
</service>
</ConfigRoot>

حالا باید Management سرویس های روی ESXi رو ریست کنید تا این فایل Custom Service  رو Load کنه.

کامند زیر رو بزنید :

 service mgmt-vmware restart

و در آخر سرویس NTPd رو ریست کنید.

 service ntpd restart

تموم شد.

خوش بگذره !!!

گاهی اوقات ممکن است در شرایطی گرفتار بگیرید که مجبور شید از Restore Network استفاده کنید .

این یعنی زمانی که  Virtual Network  و در واقع Management Network سرور ESXi شما دچار مشکل شود.

در این صورت سراغ DCUI خواهید رفت تا شبکه Management را مجدداً Config کنید.

احتمالاً یکی از راه حل‌های شما قابلیت Network Restore Option خواهد بود.

اما متاسفانه گاهی زمانی که در شرایط بسیار بدی قرار گرفته‌اید و باید در کوتاه ترین زمان ممکن شرایط را بازیابی کنید؛ این گزینه به درستی عمل نکرده و پیغام زیر را نمایش می‌دهد:

Auto Configuring Network Failed.

بر اساس KB2084090 شرکت VMware، راه حل این مشکل نصب مجدد ESXi و یا کمک گرفتن از Host Profile است!

اما بهتر است قبل از این عمل انتحاری دستورات زیر را امتحان کنید!

ساخت یک VSS جدید.

       # esxcfg-vswitch -a vSwitch1

ایجاد یک VMkernel Port Group روی VSS تازه ساخته شده برای Management.

# esxcfg-vswitch -A “Mgmt” vSwitch1

تخصیص Uplink به VSS.

# esxcfg-vswitch -L vmnic0 vSwitch1

تخصیص IP به VMkernel Port Group

# esxcfg-vmknic -a “Mgmt” -i IP Address -n Netmask

NUMA چیست؟

در توضیح NUMA باید بدانید در دهه‌ اخیر سرعت محاسبات CPUها به شکل قابل توجهی افزایش یافته است، در این شرایط دسترسی سریع و با پهنای باند بالا به حافظه بیش از پیش مورد نیاز خواهد بود.

در معماری سنتی تعداد زیادی CPU باید برای دستیابی به حافظه بر سر پهنای باند BUS رقابت می­کردند؛ این معماری را اصطلاحاً Symmetric Multiprocessing (SMP) می‌گویند.

یک راه حل برای مشکل این است که بتوانیم از طریق چندین BUS به حافظه دسترسی داشته باشیم؛ این معماری جایگزین را اصطلاحاً NUMA (Non Uniform Memory Access ) می‌گویند.

در معماری -NUMA- چند پردازنده به همراه حافظه مستقل از طریق ارتباطات High Performance با هم در ارتباط هستند؛ اصطلاحاً هر کدام از این واحد‌های مستقل CPU و حافظه را NUMA Node می‌گویند.

در معماری -NUMA- با وجود حل مشکل پهنای باند، چالش جدیدی به وجود آمده است.

واضح است که پردازش‌های روی یک Node، نیازمند اطلاعات داخل حافظه خواهند بود؛ این داده‌های مورد نیاز یا داخل حافظه محلی همان نود هستند، یا اینکه داخل حافظه سایر نودها.

به عبارتی در معماری -NUMA- دسترسی به حافظه یا Local است یا Remote.

مشکل اصلی این است که Remote Memory Access بر خلاف Local Memory Access با تاخیر همراه بوده و غیر بهینه است.

یکی از وظایف اصلی سیستم عامل این است که پردازش‌ها را به گونه‌ای Schedule کند که تا حد امکان، دسترسی به حافظه Local باشد.

مجازی سازی و NUMA

VMware از سال 2002 و از نسخه ESXi 1.5 با معماری NUMA کاملاً سازگار است.

برای همین منظور در ساختار VMkernel در کنار CPU Scheduler، ساختاری با نام NUMA Scheduler تعبیه شده است.

اگر ESXi روی سخت افزاری مبتنی بر معماری NUMA اجر شود، ماژول NUMA Scheduler فعال خواهد شد.

همچنین لازم است که قابلیت Node Interleaving (Interleaved Memory) در BIOS غیر فعال شده باشد تا ESXi سیستم را به عنوان NUMA تشخیص دهد.

علاوه بر این، سرور باید حداقل 4 CPU Core و حداقل 2 Core per NUMA Node داشته باشد.

هدف اصلی NUMA Scheduler بهینه سازی تخصیص CPU و RAM به ماشین مجازی است.

برای این منظور دو وظیفه اصلی بر عهده NUMA Scheduler گذاشته شده است:

1. Initial Placement of VMs across NUMA Nodes

هر ماشین مجازی (Virtual Machine) که توسط NUMA Scheduler مدیریت می‌شود، به یک نود اختصاص داده خواهد شد که اصطلاحاً به آن (NHN) Home Node NUMA گفته می‌شود.

زمانی که قرار است حافظه به ماشین مجازی تخصیص داده شود، ESXi تلاش خواهد کرد که حافظه را داخل Home Node اختصاص دهد و همچنین vCPUهای ماشین مجازی محدود به NUMA Home Node خواهند بود تا تضمین شود که دسترسی به حافظه Local و بهینه خواهد بود.

2. Dynamically Load Balancing VMs across NUMA Nodes

با توجه تغییراتی که در Load سیستم در طول زمان ایجاد می‌شود، امکان دارد NUMA Scheduler برای حل مشکلات عدم توازن بین نودها، NUMA Home Node یک ماشین مجازی را تغییر دهد.

به صورت پیش فرض هر 2 ثانیه یکبار سیستم بار موجود روی تمام نودها را بررسی خواهد کرد تا در صورت نیاز، Home Node یک یا چند ماشین مجازی را تغییر دهد.

اما از آنجا که اینکار ممکن است Remote Memory Access را افزایش دهد، NUMA Scheduler باید حافظه ماشین مجازی را به نود جدید منتقل کند (Page Migration).

برخی از ماشین‌های مجازی ممکن است توسط NUMA Scheduler مدیریت نشوند.

به عنوان مثال ماشین‌هایی که CPU Affinity یا Memory Affinity برای آن‌ها تعریف شده است.

بهینه سازی‌هایی که NUMA Scheduler اعمال خواهد کرد، کاملاً از دیدگاه Guest OS، Transparent خواهد بود؛

در نتیجه حتی روی سیستم عامل‌های قدیمی مثل Windows NT 4.0 که از معماری -NUMA- پشتیبانی نمی‌کنند نیز اعمال خواهد شد؛ و این خود یکی از مزایای مهم مجازی سازی است.

توجه دارید که تخصیص Physical CPU به ماشین مجازی و زمانبندی آن، همچنان وظیفه CPU Scheduler است نه NUMA Scheduler.

قبل از هر چیز لازم است که اجزای مختلف درگیر در این معماری را شرح دهیم. این اجزا در 3 لایه زیر ایفای نقش خواهند کرد:

• لایه فیزیکی
• لایه VMkernel
• لایه ماشین مجازی (VM)

در رابطه با لایه فیزیکی منظور ما از CPU Package یک CPU است که روی Socket سوار می‌شود و در ساختار خودش Core، L1 Cache، L2 Cache و Last Level Cache (LLC) دارد.

این CPU Package در کنار Local Memory متصل، تشکیل یک NUMA Node را خواهد داد.

در لایه VMkernel مفهومی با نام pCPU پیاده سازی شده است که یک Abstraction از لایه فیزیکی است.

یک pCPU می‌تواند از یک Hyper-Threading (HT) استفاده کند که اصطلاحاً به آن Logical Processor گفته می‌شود، یا اینکه یک Core را در اختیار بگیرد.

در لایه ماشین مجازی نیز مفهومی با نام vCPU و Virtual Socket وجود دارد. یک vSocket می‌تواند به یک pCPU نگاشت (Map) شود یا اینکه ممکن است یک vSocket روی چند pCPU نگاشت شود (در حالتper Socket  Multi Core).

همانطور که pCPU یک مفهومی منطقی و انتزاعی ازPhysical CPU است، vCPU هم همین نقش را برای  pCPU بازی می‌کند.

به عبارت دقیقتر vCPU یک Logical Representation و Abstraction از pCPU می‌باشد.

اما در شکل فوق هنوز اشاره‌ای به ساختار -NUMA- نشده است. در ادامه به بررسی ساختار -NUMA- در معماری ESXi خواهیم پرداخت.

گفتیم که وظیفه اصلی NUMA Scheduler یکی Initial Placement و دیگری Load Balancing بین NUMA Nodeهاست.

NUMA Scheduler برای این منظور دو ساختار منطقی با نام NUMA Home Node (NHN) و NUMA Client ایجاد کرده است.

بیشتر بخوانید : مجازی سازی سرور

NUMA Home Node NHN

NHN یک Logical Representation از CPU Package و Local Memory آن است.

NUMA Scheduler، Physical Coreهای موجود در CPU Package را شمارش می‌کند.

سپس نتیجه را با vCPUهای ماشین مجازی مقایسه می‌کند. این مقایسه برای Initial Placement و Load Balancing بسیار مهم است.

چنانچه تعداد vCPUهای یک ماشین مجازی بیشتر از تعداد Coreهای فیزیکی موجود در CPU Package باشد، لازم است که آن VM روی چند NUMA Node توزیع شود.

واضح است که با کاهش منطقی vCPUها می‌توان از این توزیع شدن روی چند NUMA Node جلوگیری کرد؛ هرچند که گاهی اوقات اجتناب ناپذیر خواهد بود!

به صورت پیش فرض فقط Coreها شمارش خواهد شد و Hyper-Threading را وارد بازی نخواهیم کرد!

توجه داشته باشید که فقط مساله شمارش vCPU و Physical Core نیست!

اگر RAM اختصاصی به یک ماشین مجازی بیشتر از RAM موجود در یک NUMA Node باشد، باز هم ناگزیر ماشین‌ مجازی روی چند NUMA Node توزیع خواهد شد هرچند که به صورت پیش فرض، NUMA Scheduler نسبت به این مساله ناآگاه است که در نهایت اگر مواظب نباشید باعث افت کارایی خواهد شد.

حال وظیفه NUMA Scheduler این است که تمام تلاش خود را انجام دهد تا به ماشین مجازی Local Memory تخصیص داده شود تا درگیر عملیات پر هزینه Remote Memory Access نشویم.

NUMA Client

یک NUMA Client، شامل vCPUها و حافظه‌های ماشین مجازی است که داخل یک NUMA Home Node جا (fit) می‌شوند.

NUMA Client کوچکترین واحدی است که NUMA Scheduler از آن برای Initial Placement و Load Balancing استفاده می‌کند.

وقتی یک ماشین مجازی را روشن می‌کنید، تعداد vCPUها شمارش و با تعداد Coreهای فیزیکی مقایسه می‌شود؛

اگر vCPUها کمتر بودند، یک توپولوژی Virtual UMA (Uniform Memory Access) به همراه یک Uniform Memory Address Space در اختیار ماشین مجازی قرار خواهد گرفت؛

در غیر این صورت باید چند NUMA Client برای آن ماشین مجازی ایجاد شود.

به عنوان مثال اگر یک ماشین مجازی با 12 vCPU بخواهد روی یک سرور با CPU Package-10 Core روشن شود، باید دو NUMA Client ساخته شود و vCPUها به صورت مساوی بین این دو NUMA Client پخش شود.

یک نکته بسیار مهم وجود دارد که توجه به آن حیاتی است!

بر خلاف آنچه در شکل فوق مشاهده می‌کنید، هیچ گونه وابستگی بین pCPUها (vCPUها) و NUMA Client وجود ندارد.

CPU Scheduler برای توازن و بهینه سازی، آزادانه می‌تواند تصمیم بگیرد که یک vCPU را روی هر کدام از pCPUهایی که CPU Package در اختیارش قرار داده، Schedule کند.

vNUMA Node

چنانچه برای یک ماشین مجازی بیش از یک NUMA client ایجاد شود، اصطلاحاً آن ماشین مجازی را Wide-VM می‌نامند.

در این شرایط NUMA Scheduler با هدف بهینه سازی بیشتر، برای این ماشین مجازی یک توپولوژی اختصاصی با نام Virtual NUMA (vNUMA) خواهد ساخت.

vNUMA مستقیماً در اختیار Guest OS قرار خواهد داد تا لازم نباشد ماشین مجازی و سیستم عامل درگیر توپولوژی -NUMA- سرور فیزیکی (PNUMA) شوند. این قابلیت از ESXi نسخه 5 و VM Version نسخه 8 به بعد معرفی شد.

به عنوان مثال در همان سناریو قبلی، وقتی یک ماشین مجازی با 12 vCPU می‌سازیم، -vNUMA- دو نود مجازی که هر کدام 6 vCPU دارد به سیستم عامل ارائه می‌کند؛

این موضوع باعث می‌شود اجازه دهیم خود Guest OS بتواند مستقلاً یک لایه NUMA Optimization را اعمال کند.

اگر قرار باشد به هر دلیلی بیش از یک vNUMA Client برای یک ماشین مجازی ایجاد شود، NUMA Scheduler مسئول Auto-Sizing برای vNUMA Clientها خواهد بود.

به صورت پیش فرض باید vCPUها به صورت مساوی بین کمترین تعداد NUMA Clientها تقسیم شوند.

عملیات Auto-Sizing در اولین باری که ماشین مجازی روشن شود، انجام خواهد گرفت.

در زمان اولین بار بوت شدن ماشین مجازی دو خط زیر به Advanced Settings ماشین مجازی افزوده خواهد شد:

numa.autosize.vcpu.maxPerVirtualNode=X

numa.autosize.cookie = ‘XXXXXX’

این تنظیمات تا زمانی که تعداد vCPUهای ماشین مجازی تغییر نکند، ثابت باقی خواهد ماند.

از طرفی عملیات Auto-Sizing با توجه به معماری Physical NUMA سروری انجام خواهد شد که ماشین مجازی برای اولین بار روی آن روشن شده است.

در نتیجه اگر کلاستری داشته باشیم که معماری -NUMA- سرورهای آن با هم متفاوت باشد، در نتیجه عملیات vMotion ممکن است به شدت باعث افت کارایی ماشین‌های مجازی شود.

در چنین شرایطی حتی Reboot کردن ماشین مجازی به امید Auto-Sizing مجدد با توجه به معماری جدید نیز بی‌فایده خواهد بود؛ مگر اینکه از دو تنظیم زیر در Advanced Settings ماشین مجازی استفاده کنیم:

numa.autosize.once = FALSE

numa.autosize = TRUE

اینکار باعث خواهد شد که بعد از هر Power-cycle و بعد از هر بار vMotion، NUMA Scheduler مجبور باشد که NUMA Client Size را تغییر دهد.

به شدت مواظب استفاده از این دو تنظیم باشید؛  چرا که لزوماً تمام Workloadها با تغییرات جدید NUMA Client Size به خوبی کنار نخواهند آمد!!

این خود انگیزه بسیار قدرتمندی خواهد بود تا شما را مجاب سازد کلاسترهایی با معماری یکسان (Homogeneous) ایجاد کنید.

تنظیمات پیشرفته معماری vNUMA

ممکن است شرایطی پیش آید که بخواهیم بنا به دلائلی، اندازه پیش فرض NUMA Client را تغییر دهیم؛

برای این منظور می‌توان از پارامترهای زیر جهت تغییر رفتار پیش فرض استفاده کنیم (هر چند این کار توصیه شده نیست، مگر اینکه آگاهی کامل از نتیجه کار داشته باشید!).

1. numa.vcpu.min

به صورت پیش فرض -vNUMA- تنها برای ماشین‌هایی ایجاد خواهد شد که یکی از شرایط زیر را داشته باشند:

* ماشین‌هایی که تعداد vCPUهای آن‌ها 9 یا بیشتر باشد.

* زمانی که تعداد vCPUهای ماشین مجازی بیشتر از تعداد Coreهای یک CPU Package باشد. گفتیم که این شمارش فقط تعداد Coreهای فیزیکی را در نظر خواهد گرفت نه Logical Processorها را!

با استفاده از این تنظیم می‌توان این حداقل، یعنی عدد 9 را تغییر داد، تا برای ماشین‌هایی با vCPU کمتر نیز vNUMA ساخته شود.

2. numa.vcpu.maxPerMachineNode

ممکن است برنامه‌ای داشته باشیم که حساس به Memory Bandwidth باشد نه Memory Access Latency! در چنین شرایطی حالت بهینه، بر خلاف حالت پیش فرض این خواهد بود که ماشین مجازی روی NUMA Nodeهای بیشتری توزیع شود تا پهنای باند بیشتری برای دسترسی به Memory داشته باشد.

این تنظیم به ما اجازه می‌دهد حداکثر تعداد vCPUهایی که داخل یک NUMA Client قرار خواهند گرفت را تغییر دهیم تا NUMA Clientهای بیشتری ساخته شود.

3. Count Threads Not Cores

با استفاده از تنظیم numa.vcpu.preferHT=TRUE می‌توان NUMA Scheduler را مجبور کرد که در زمان شمارش، به جای شمارش Coreهای فیزیکی، تعداد Threadها یا Logical Processorها را مد نظر قرار دهد.

با استفاده از این تنظیم ممکن است بتوانیم شرایطی را ایجاد کنیم که یک Wide-VM بتواند روی یک NUMA Node، fit شود. به عنوان مثال یک ماشین مجازی با 12vCPU روی یــــک سرور 2 Socket – 10 Core، دو NUMA Client ایجاد خواهد کرد (6-6).

اما با استفاده از numa.vcpu.preferHT=TRUE، NUMA Scheduler می‌تواند یک NUMA Client بسازد تا تمام vCPUها را روی یک CPU Package قرار دهد.

مجدداً توجه به این نکته ضروری است که در این حالت هم CPU Scheduler لزوماً مجبور نخواهد بود یک vCPU را روی یک Logical Processor (HT)، اجرا کند. CPU Scheduler همچنان تلاش خواهد کرد که یک vCPU بتواند یک Physical Core را تصاحب کند.

این موضوع بر عهده CPU Scheduler است نه NUMA Scheduler و وابسته به Ratio CPU Overcommitment در محیط است.

با وجود اینکه تکنولوژی Hyper-Threading در محیط‌ مجازی CPU Utilization را افزایش خواهد داد و Overall Performance را در حدود 10-15% بهبود خواهد بخشید؛ اما همانطور که می‌دانید، Logical Processorها منابع یک Physical Core را به اشتراک خواهد گذاشت؛

در نتیجه CPU Progression در مقایسه با حالتی که پردازش­ها‌ Physical Core را در اختیار دارند، کاهش خواهد یافت.

از اینرو لازم است بررسی کنیم که آیا ماشین مجازی و برنامه‌هایی که قرار است روی آن اجرا شوند، Cache Intensive هستند یا CPU-cycle Intensive؟ استفاده از numa.vcpu.preferHT=TRUE به CPU Scheduler دستور می‌دهد تا Memory Access را نسبت به CPU Resource در اولویت قرار دهد. همانطور که گفته شد، برای فعال کردن این گزینه، کاملاً آگاهانه و با تست کامل اقدام کنید؛ در غیر این صورت مقدار پیش فرض (False) را تغییر ندهید.

واضح است که در این شرایط هم لازم است میزان حافظه تخصیص داده شده به ماشین مجازی، کمتر یا مساوی با حافظه NUMA Node باشد، در غیر این صورت Remote Access اتفاق خواهد افتاد و کارایی preferHT را کاهش خواهد داد!

تنظیم این گزینه Per-VM خواهد بود، هر چند که می‌توان در صورت نیاز این گزینه را در سطح Host فعال کرد (KB2003582).

اگر این تنظیم را برای یک ماشین که قبلاً یکبار روشن شده است، اعمال کنیم، بنا به دلائلی که پیشتر گفته شد، تاثیری نخواهد داشت و نیاز به استفاده از تنظیمات تکمیلی دیگری خواهد بود.

4. Cores per Socket

تنظیم Core per Socket (GUI) یا cpuid.coresPerSocket (Advanced Settings) به صورت پیش فرض روی عدد یک تنظیم شده است.

تغییر مقدار پیش فرض و افزایش آن باعث خواهد شد که -vNUMA- مستقیماً ساخته شده و در اختیار VM قرار گیرد که لزوماً ممکن است بهینه نباشد.

البته از نسخه 6.5 به بعد، این تنظیم دیگر تاثیری در رفتار vNUMA نخواهد داشت و vNUMA تحت هر شرایطی حالت بهینه را در اختیار Guest OS قرار خواهد داد.

چگونه به معماری vNUMA دسترسی داشته باشیم؟

در داخل فایل VMware.log هر ماشین مجازی اطلاعاتی در رابطه با معماری و ساختار vNUMA وجود دارد. اما به جای دانلود و بررسی خط به خط این فایل می‌توان از دستور زیر استفاده کرد:

vmdumper -1 | cut -d \/ -f 2-5 | while read path; do egrep -oi DICT.* (displayname.*|numa.*|cores.*|vcpu.*|memsize.*|affinity.*)=.*|Inuma:.*|numaHost:.*’ “/$path/vmware.log”; echo -e; done

توجه داشته باشیم که برای کسب اطلاعات کامل، لازم است که حداقل یکبار ماشین مجازی روشن شده باشد تا ساختار NUMA Client، Auto-Size شده باشد.

در تاریخ 17 مرداد 1397 (18 آگوست 2018) متخصصان شرکت Intel یک آسیب پذیری جدی با نام L1 Terminal Fault (L1TF) را روی طیف وسیعی از پردازنده‌های Intel شناسایی کردند.

این آسیب پذیری باعث خواهد شد که یک کاربر با دسترسی محلی بتواند از طریق Terminal Page Fault و Side-Channel Analysis، به محتویات L1 Cache پردازنده دسترسی پیدا کند!

پردازنده‌های تحت تاثیر این آسیب پذیری عبارتند از:

Intel ® Core™ i3 processor (45nm and 32nm )

Intel ® Core™ i5 processor (45nm and 32nm )

Intel ® Core™ i7 processor (45nm and 32nm )

Intel® Core™ M processor family (45nm and 32nm)

2nd generation Intel® Core™ processors

3rd generation Intel® Core™ processors

4th generation Intel® Core™ processors

5th generation Intel® Core™ processors

6th generation Intel® Core™ processors

7th generation Intel® Core™ processors

8th generation Intel® Core™ processors

Intel® Core™ X-series Processor Family for Intel® X99 platforms

Intel® Core™ X-series Processor Family for Intel® X299 platforms

Intel® Xeon® processor 3400 series

Intel® Xeon® processor 3600 series

Intel® Xeon® processor 5500 series

Intel® Xeon® processor 5600 series

Intel® Xeon® processor 6500 series

Intel® Xeon® processor 7500 series

Intel® Xeon® Processor E3 Family

Intel® Xeon® Processor E3 v2 Family

Intel® Xeon® Processor E3 v3 Family

Intel® Xeon® Processor E3 v4 Family

Intel® Xeon® Processor E3 v5 Family

Intel® Xeon® Processor E3 v6 Family

Intel® Xeon® Processor E5 Family

Intel® Xeon® Processor E5 v2 Family

Intel® Xeon® Processor E5 v3 Family

Intel® Xeon® Processor E5 v4 Family

Intel® Xeon® Processor E7 Family

Intel® Xeon® Processor E7 v2 Family

Intel® Xeon® Processor E7 v3 Family

Intel® Xeon® Processor E7 v4 Family

Intel® Xeon® Processor Scalable Family

Intel® Xeon® Processor D (1500, 2100)

این آسیب پذیری علاوه بر اینکه سیستم عامل‌ها در محیط‌های فیزیکی را تحت تاثیر قرار می‌دهد، باعث آسیب پذیری در محیط‌های مجازی و Hypervisor ها نیز خواهد شد. در این پست می‌خواهیم در مورد این آسیب پذیری در محیط‌های مجازی صحبت کنیم.

جهت کسب اطلاعات بیشتر به INTEL -SA-00161 و CVE-2018-3646 مراجعه کنید.

L1 Terminal Fault – VMM

این آسیب پذیری در محیط‌های مجازی می‌تواند باعث شود یک ماشین مجازی Malicious  که در حال حاضر یک Core را در اختیار گرفته (توسط Hypervisor روی آن Schedule شده است)، قادر باشد به واسطه L1 Cache، به اطلاعات سایر ماشین‌های مجازی یا حتی خود VMkernel دسترسی پیدا کند!

این مشکل خصوصاً در زمانی که قابلیت  Hyperthreading فعال باشد، بیشتر از پیش مشکل ساز خواهد شد.

به طور کلی دو نوع خطر برای این آسیب پذیری متصور خواهد بود:

1. Sequential-Context Attack: در این حالت Malicious VM زمانی که یک Logical Processor (در صورت فعال بودن Hyperthreading) و یا Core Processor را در اختیار می‌گیرد، به محتویات L1 Cache، Context قبلی (ماشین مجازی یا VMkernel) دسترسی خواهد داشت! توجه داشته باشید که در این حالت پردازش قبلی یا به عبارت دقیق‌تر ماشین مجازی یا VMkernel که این Processor را در اختیار داشته، با وجود تحویل منابع به Malicious VM، هنوز اطلاعات خود را در داخل L1 Cache باقی گذاشته است.

حل این مشکل چندان پبچیده نیست! مسلماً لازم است که Hypervisor قبل از تحویل منابع به ماشین مجازی تازه Schedule شده، محتویات L1 Cache پردازش‌ قبلی را خالی کند (مکانیزمی که ESXi برای تحویل حافظه رم هم از قبل استفاده می‌کرد).

برای این منظور کافی است Patchها و Updateهای مربوط به ESXi را نصب کنید.

توجه دارید که این کار مشکل Sequential-Context Attack را حل خواهد کرد اما بلاشک خالی شدن اطلاعات Cache کارایی را اندکی کاهش خواهد داد.

بر اساس اعلام شرکت VMware این افت کارایی کمتر از 3% خواهد بود!

جدول زیر خلاصه‌ای از نتایج مربوط به افت کارایی پس از انجام بروز رسانی‌های مربوطه است که توسط شرکت VMware تست و اعلام شده است.

2. Concurrent-Context Attack: این مدل از حملات مربوط به زمانی است که Hyperthreading روی BIOS و ESXi فعال است. در این شرایط Malicious VM همزمان در کنار یک ماشین مجازی دیگر و یا خود VMkernel در حال اجرا و استفاده از L1 Cache است.
   واضح است که در این حالت نمی‌توان Cache را پاک سازی کرد! حل این مشکل کمی پیچیده‌تر خواهد بود.
   شرکت VMware یک قابلیت جدید با نام ESXi Side-Channel-Aware Scheduler معرفی کرده است که در پیاده سازی نسخه اولیه، اجازه نخواهد داد که دو ماشین مجازی روی یک Core همزمان اجرا شوند بلکه فقط VMkernel می‌تواند در کنار VM روی یک Core با قابلیت Hyperthreading قرار بگیرد!

اما دو نکته مهم…

اولاً شخصاً معتقدم که این راه حل هنوز کامل نیست؛ چراکه هنوز خود VMkernel در معرض خطر است.
به نظر من حذف کامل این آسیب پذیری نیازمند همکاری شرکت Intel و ارائه راه حل‌های سخت افزاری خواهد بود.
شاید هم یک راه حل، حذف صورت مساله و چشم پوشی از مزایای Hyperthreading با غیر فعال سازی آن باشد.

ثانیاً اگر قرار باشد ESXi Side-Channel-Aware Scheduler فعال شود، می‌تواند تاثیر بسیار مخربی در عملکرد محیط شما داشته باشد و Performance را به شدت کاهش دهد (دیگر دو ماشین مجازی بر خلاف گذشته نمی‌توانند همزمان روی یک Core زمانبندی شوند)!
متاسفانه این قابلیت تمام امیدها و دانش قبلی ما در رابطه با تخصیص vCPU، نسبت vCPU:PCPU و… را به شکل ویران کننده‌ای به چالش خواهد کشید و شما را در دو راهی بین امنیت و Performance قرار خواهد داد!!

بر اساس اعلام شرکت VMware، حداکثر افت کارایی در صورت فعال سازی ESXi Side-Channel-Aware Scheduler برابر 30% خواهد بود (شخصاً اعتقاد چندانی به صداقت این عدد ندارم!). دو جدول زیر خلاصه‌ای از نتایج مربوط به این آزمایشات را نمایش می‌دهد.

اگر در محیط مجازی شما یکی از شرایط لیست زیر برقرار باشد، احتمالاً با فعال سازی ESXi Side-Channel-Aware Scheduler، با مشکلاتی مواجه خواهید شد و نیاز خواهد بود که یا از این کار منصرف شوید، یا اینکه در این شرایط بد اقتصادی بودجه بیشتری تخصیص داده و منابع پردازشی خود را افزایش دهید!

• VMهایی دارید که تعداد vCPU تخصیص داده شده به آن‌ها بیشتر از Physical Coreهای موجود سرور است (قبلاً Logical Processor برای ما ملاک بود).
• VMهایی دارید که Latency-Sensitive را برای آن‌ها تنظیم کرده‌ایم.
• سرورهایی داریم که میانگین CPU Usage آن‌ها از 70% بیشتر است.
• کلاستری دارید که در شرایطی نظیر Rolling Upgrade، میانگین CPU Usage به 100% نزدیک می‌شود.

اگر هنوز هم بین دو راهی فعال سازی یا عدم فعال سازی این قابلیت امنیتی قرار گرفته‌اید، نگاهی به درخت تصمیم زیر بیندازید….

 همانطور که در شکل مشاهده می‌کنید، عدم فعال سازی این قابلیت، منوط به ارزیابی‌های دقیق امنیتی (Risk Assessment) و اعتماد کامل به محیط است. در هر صورت VMware عدم فعال سازی را به هیچ وجه توصیه نکرده است!

همچنین شرکت VMware در راستای کمک به انجام فرآیند تصمیم گیری و فعال سازی ESXi Side-Channel-Aware، ابزاری با نام HTAware Mitigation Tool معرفی کرده است که با مانیتورینگ محیط شما و شناسایی مشکلات بالقوه در صورت فعال سازی این قابلیت، شما را در تصمیم گیری کمک خواهد نمود.
پیشنهاد میکنم حتماً از این ابزار استفاده کنید! راهنمای کاملی از این ابزار و همچنین لیک دانلود در KB56931 موجود است.

در نهایت در صورتی که تصمیم نهایی خود را گرفتید و خواستید ESXi Side-Channel-Aware را فعال کنید کافی است، سرور ESXi خود را انتخاب کنید، به قسمت Configuration و سپس Settings رفته و Advanced System Settings را انتخاب کنید. دکمه Edit را بزنید و VMkernel.Boot.hyperthreadingMitigation را از false به true تغییر دهید و یا از دستور زیر استفاده کنید.

esxcli system settings kernel set -s hyperthreadingMitigation -v TRUE

جهت کسب اطلاعات بیشتر به KB55806 و KB55767 مراجعه فرمایید.

مقدمه

مدت زمان بسیار زیادی هستش که هر سایتی به یه نحوی NUMA رو آموزش میده و میگه که ماشین مجازی چجوری باید درست شه  و CPU های آنها چجوری باید اختصاص پیدا کنه.

همه بر این اعتقاد هستند که اگر مدلی که اونها میگن ، CPU را اختصاص ندهید نه تنها باعث کندی ماشین مجازی میشید بلکه در نهایت باعث میشه برید جهنم !!!

تو این مطلب آموزشی می خوام برای اولین و آخرین بار این موضوع رو به صورت کامل با هم بررسی کنیم و پروندش رو ببندیم بزاریم کنار( البته تا زمانی که VMware دوباره تغییری روش نده که بعید میدونم بیشتر از 5 6 ماه باشه)

اول از همه NUMA رو ببینیم چیه .

این NUMA چیست ؟

NUMA یا همون Non-Uniform Memory Access مدلی از طراحی سخت افزاره که در سرور های چند CPU استفاده میشه.

کلا حرفش اینه :

استفاده از مموری کاملا بستگی به مکان قرار گرفتن مموری نسبت به CPU داره .

این عکس رو ببنید:

اگر قرار باشه CPU بالایی توعکس از رم استفاده کنه، سخت افزار بهش میگه بیا از رم های نزدیک خودت استفاده کن.

پس CPU بالایی تو عکس از رم های بالای خودش استفاده می کنه و سراغ رم های پایین نمیاد.

برای همین میگن پس رم های نزدیک هر CPU میشه Cache local اون CPU . نهایتا باعث میشه سرعت ارتباط رم با پروسس ها خیلی افزایش پیدا کنه.

قبلا اینطوری نبود . از یک تکنولوژی استفاده می کردند به نام SMP یا Symmetric Multi Processing ، تو اون کل رم ها ، میومدن وسط دو تا CPU به صورت کامل Share می شدن و جفت CPU ها ازشون استفاده می کردند.

فکر کنم شکل پایین حق مطلب رو ادا میکنه.

حالا بریم ببینیم وقتی که داریم از NUMA استفاده می کنیم VMware چی میگه؟ چجوری استفاده کنیم که سرعتمون روی ماکزیمم باشه؟

نظر VMware درباره NUMA

طبق آخرین داکیومنت VMware در مورد NUMA که برای June سال 2018 هستش، ساختار NUMA رو باید طبق روشی که می خوایم بگیم پیاده سازی کنید.

البته اگر دوست دارید میتونید از این لینک برید و مقاله یک بزرگوار دیگه رو هم راجع تغییرات 6.5 آپدیت 1 به بعد بخونید :

http://frankdenneman.nl/2016/12/12/decoupling-cores-per-socket-virtual-numa-topology-vsphere-6-5

راستی قبلش بگم که vNuma چیه ؟

اون چیزی که بالا راجع بهش صحبت کردیم NUMA نیست در واقع pNUMA هستش . ما یه چیزی هم داریم به نام vNUMA.

vNUMA زمانی درست میشه  که بیشتر از 8 عدد CPU به یک ماشین مجازی میدیم و ESXi سعی می کنه همانطور که pNUMA داره باعث افزایش سرعت میشه اون قابلیت رو دست ماشین مجازی هم  برسونه .

شروع می کنیم

اولین نکته ای که باید در نظر بگیرید اینه که کلا هنگام اختصاص دادن vNuma به ماشین مجازی ، ESXi به مموری شما نگاه نمیکنه.

یعنی خودتون باید دستی حواستون باشه که چقدر مموری دارید به ماشین مجازی اختصاص میدید.

اگر نحوه محاسبه مموری رو میدونید که بگذرید اگر نه این خط های سبز رنگ زیر رو بخونید.

فرض کنید یه سرور دارید که دو تا CPU داره که هر کدوم 10 تا Core دارند سرور جمعا 256 گیگ رم داره که تقسیم بر دو کنیم ( با فرض اینکه رم های CPU را به تعداد مساوی نصب کردید) هر CPU مقدار 128 گیگ رم داره.

پس هر 10 Core و 128 گیگ رم  یک pNuma Node میشه.

یعنی اگر ماشینی داشته باشیم با 8 تا CPU و 100 گیگ رم، برای این ماشین یک vNuma Node درست می کنه که چون از pNUMA Node کوچکتره در داخل همون قرار می گیره.

درست مثل VM1 تو شکل زیر.

حالا که چی ؟

یک نگاه به عکس زیر بندازید :

این صفحه مشکل تمام ادمین های مجازی سازی هستش. که تعداد Core ها رو یک بدن یا تعداد Socket ها رو یک بدن یا کلا تعداد همه رو متغیر بدن.

من سه سناریو رو براتون بررسی می کنم که خودتون متوجه شید کدومش بهتره :

صورت مسئله سناریو

سرور فیزیکی ما 2 عدد CPU داره که هر کدوم 8 Core دارن و 128 گیگ رم داره.

می خواهیم یک ماشین مجازی با Resource بالا بسازیم ، نظر شما در مورد مقدار Ram و CPU آن چیست ؟

راه حل :

اول میریم pNuma Node رو محاسبه می کنیم که سایز اون میشه : 

• 8 CPU
• 64 گیگ رم

مدل های درست کردن ماشین : 

• تعداد رم و CPU را کمتر از یک pNuma Node نگه داریم  یعنی ماکزیمم 8 تا CPU و 64 گیگ رم که برای این ماشین یک vNuma درست می کند که در داخل pNuma ما قرار میگیرد.
• مقدار CPU را زیر 8 Core نگه داریم ولی مقدار رم را 100 گیگ بگیریم : که چون ESXi برای محاسبه NUMA به رم نگاه نمیکنه باز هم برای این ماشین یک vNUMA درست می کنه اما چون رم اون بالاتر از رم یک pNUMA Node هستش مجبور میشه بین دو تا pNuma Node این ماشین رو Share کنه .در مثل VM2 تو شکل زیر :
•  

• مدل سوم که بهینه ترین می باشد مدلی هستش که تعداد رم و CPU رو بیشتر از یک pNuma Node بدیم . یعنی به ماشین مجازی 12 Core و 96 گیگ رم بدیم. برای این کانفیگ باید به ماشین بگیم از دو CPU Socket استفاده کنه یعنی  : 
  • 2 سوکت 6 Core بهش بدیم
  • که در این حالت از هر طرف 48 گیگ رم بر میداره.

عکس زیر رو ببینید.

برای اینکه همیشه بهترین مدل CPU را اختصاص بدیم نکات زیر را همیشه در نظر داشته باشید :

• تنظیمات پیشرفته NUMA رو روی ESXi رو تغییر ندهید.
• همیشه تعداد CPU را محدود به یک Socket و تعداد رم را محدود رم یک pNUMA Node اختصاص بدید در غیر اینصورت تعداد CPU را به صورت موازی پخش کنید ( حواستون باشه که مقدار رم برای محاسبه vNuma Node در گیر نیست باید با تعداد CPU تعداد vNuma Node رو مشخص کنید)
• به هیچ وجه زمانی که تعداد vCPU های شما بیشتر از یک سوکت میشه تعداد vCPU ها را عدد فرد نزنید. یعنی هیچ وقت به ماشین 7 یا 9 تا vCPU ندید.
• کلا CPU Hot Add رو روشن نکنید چون با روشن کردنش vNUMA به صورت کامل Disable میشه.
• هیچ وقت ماشینی با تعداد CPU بیشتر از تعداد CPU هاستتون درست نکیند.

در آخر برای اینکه مطلب براتون کاملِ کامل جا بیافته مثال زیر رو ببنید.

مثال آخر

جدول زیر نحوه درست اختصاص CPU به ماشین مجازی در سروری با مشخصات زیر رو نشون میده :

• دو عدد CPU که هر کدوم 10 Core دارند.

مقدمه

همانطور که میدونیم بستر مجازی سازی سرور شرکت VMware با نام تجاری vSphere 6.7 فعالیت می کنه.

این بستر با توجه به قابلیت هایی که ارائه می کنه به ما کمک می کنه که در بالاترین سطح بتوانیم SLA خودمون رو ارائه کنیم.

با معرفی هر ورژن، این شرکت قابلیت های خیلی زیاد و پیشرفته ای به اون اضافه می کنه،که در این مطلب آموزشی سعی می کنیم قابلیت های ورژنvSphere 6.7 را با هم ببینیم.

مدیریت آسان تر در Scale بزرگتر

در vSphere 6.7 ، پارت مدیریت سرورها یعنی vCenter پیشرفت بسیار زیادی در Performance داشته به عنوان مثال موارد زیر را بخوانید :

• تعداد عملیات هایی که در ثانیه انجام می ده نسبت به 6.5 دو برابر شده.
• حجم استفاده از رم به یک سوم رسیده.
• عملیات های مربوط به DRS را در یک سوم زمان ورژن قبل انجام می ده به عنوان مثال روشن کردن ماشین اگر در وژن 6.5 حدود یک ثانیه طول می کشید الان در 0.3 میلی ثانیه انجام می شه.

این افزایش سرعت و بهره وری باعث می شه که ادمین های مجازی سازی یعنی ما، کیفیت خیلی بهتری دریافت کنیم و راحت تر بتونیم با vCenter کار کنیم.

این قابلیت های ورژن 6.7 فقط به vCenter ختم نمی شه. یکی از قابلیت هایی که خیلی وقت بود بر روی ESXi منتظر اون بودم قابلیت Quick Boot هستش.

Quick Boot در vSphere 6.7

همانطور که میدونید یکی از مشکلاتی که ادمین های مجازی سازی با سرور های فیزیکی ESXi داشتیم مشکل ریبوت هستش.

متاسفانه ریبوت سرور فیزیکی باید در زمان های خاصی انجام شه مثلا :

• آپدیت ESXi
• نصب VIB جدید و ،،،،،،

قابلیت فوق العاده ای که در ورژن vSphere 6.7 داریم قابلیت Quick Boot هستش. این قابلیت Hypervisor رو ریبوت می کنه ولی سرور فیزیکی رو ریبوت نمیکنه.

اگر تا حالا با استفاده از VUM سرور ESXi رو آپدیت کرده باشید می دونید که برای آپدیت دو بار ESXi رو ریبوت می کنه با استفاده از این قابلیت این تعداد به یک عدد کاهش پیدا می کنه برای همین باعث میشه زمان Downtime ما خیلی کاهش پیدا کنه.

به نظرم این قابلیت VMware رو خیلی نسبت به بقیه Hypervisor ها جلو میندازه (البته تا الانش هم خیلی جلوییم :))

HTML5 UI

یکی دیگه از قابلیت هایی که به این ورژن اضافه شده UI بسیار خوشگل vCenter هستش.

نه تنها زیبایی بهش اضافه شده خیلی Responsive هم هستش .تمامی کارهاتون مطمئنا با نصف زمان انجام میشه.

شاید از خودتون بپرسید که این قابلیت قبلا هم بودش ولی توجه به این نکته نکردید که در ورژن 6.5 مدل ارائه HTML 5 به صورت Partially released بود.

در ورژن 6.7 به صورت Full release هستش و شما می توانید NSX و VSAN و تمام راهکارهای ثانویه را با استفاده از HTML5 UI مدیریت کنید که بسیار لذت بخش هستش.

در پایین برای کسانی که تا حالا این محیط رو ندیدن عکس نمونه ای آپلود می کنم.

امنیت مثال زدنی در  vSphere 6.7

همه قابلیت های امنیتی که VMware به 6.5 اضافه کرد در 6.7 پیشرفته تر شده.

در 6.5 قابلیت های VM Encryption و vMotion Encryption رو داشتیم که در 6.7 نیز وجود دارند با این تفاوت که ساده تر شده اند و حالا شما میتوانید ماشین مجازی را بین دو vCenter به صورت Encrypt شده جابجا کنید.

مورد بعدی که بهینه شده  پروتکلی به نام TPM Trusted Platform Module بود، که الان توضیحش رو با هم میخونیم.

TPM Trusted Platform Module

یکی از قابلیت هایی که در ورژن 6.5 داشتیم Secure Boot بودش.

این بزرگوار زمانی که سرور ESXi داره بوت میشه Signature موجود روی BIOS رو چک میکنه که مورد تایید خودش باشه.

حالا TPM که میاد وسط میگه موقع بوت من فقط اجازه میدم که Deviceهای که Signature تایید شده من رو دارم بعد از بوت کار کنند.

در 6.7 قابلیت TPM 2 یا vTPM 2 رو معرفی کرده که اجازه میده تمامی قابلیت های امنیتی سیستم عامل Guest OS با سخت افزار چک شه به زبان بسیار ساده همون TPM رو در داخل سیستم عامل ویندوز یا لینوکس انجام میده.

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

• یکی از قابلیت های که در vSphere 6.7 اضافه شده قابلیت استفاده از کارت گرافیکی nVIDIA بر روی Non-VDI سیستم هستش.

الان از خودتون میپرسی به چه درد می خوره ؟ الان توضیح می دم.

احتمالا این جمله رو چند باری تا حالا شنیدید که هکر ها به جای CPU از قدرت GPU استفاده می کنند چون خیلی سریع تر هستش.

اینم دقیقا همین کار رو میکنه . ESXi بهتون اجازه میده که از قدرت Compute کارت گرافیکی استفاده کنید  مثلا برای هوش مصنوعی و … .

در ضمن با همکاری که VMware با nVidia داشته ، از این به بعد می تونید روی کارت گرافیک های خاصی مثل Grid ماشین رو Suspend و Resume کنید که این بع معنی که میتونید روی ماشین های که vGPU دارند عملیات vMotion هم داشته باشید.

• یکی دیگه از قابلیت ها استفاده از Persistent Memory هستش.

از این مموری ها می تونیم به عنوان یک استوریج پر سرعت استفاده کنیم یا اینکه مثل ورژن قبلیش قابلیت استفاده از NVM Non Volatile Memory رو داشته باشیم. بهتره روی Persistent Memory ها مطالعه کنید چون بازارش خیلی داره داغ میشه.

عکس زیر روببینید.