در این ورژن از مدیریت بستر مجازی سازی یعنی vCenter 6.7 Update 2 قابلیت های جدیدی مانند :
– DRS در Maintenance Mode
– حل برخی از مشکلات امنیتی CPU
– اضافه شدن لایسنس vSphere ROBO
– و آپدیت جدید vSphere Platinum
علاوه بر حل شدن بسیاری از باگ های موجود در این بستر توسط VMware در این ورژن بهبود های زیادی هم حاصل شده.
در ادامه مطلب به تکتک این عناوین اشاره میکنیم.
vCenter Server Architecture
VMware به تازگی اعلام کرده که از ورژن بعدی قابلیت پیاده سازی vCenter با استفاده ازExternal Platform Service Controller را حذف خواهد کرد.
دقت داشته باشید از ورژن بعدی نه از آپدیت بعدی.
به این معنی که از ورژن بعدی تنها مدل پیاده سازی vCenter به صورت Embedded خواهد بود.
اگر به عکس زیر دقت کنید به صورت کاملا واضح این مسئله را بیان می کنه.
vCenter 6.7 Update 2
Converge Tool
اگرچه این ابزار در آپدیت اول نیز وجود داشت ولی شما فقط می تونستید اون را از طریق CLI پیاده سازی کنید.
اما در آپدیت ۲ این قابلیت به صورت پیش فرض درvSphere Client موجود می باشد.
در این ورژن شما می تونید به صورت Table view تمامی vCenter های خود را ببینید و به راحتی با کلیک بر روی هرکدام، اونها را از حالت External به حالت Embedded تبدیل کنید.
فقط باید حواستون باشه که تمامی راهکارهای 3rd Party را نیز به سمت این PSC Embedded دوباره Point کنید.
File-Based Backup and Restore
آپدیت 2 محصول vCenter از پروتکل های ذخیره سازی مثل NFS و SMB پشتیبانی می کند و به کاربر این اجازه را می دهد که از کانفیگ vCenter بک آپ بگیرند.
با اضافه شدن این دو پروتکل مجموع پروتکل ها 7 عدد میشه :
– HTTPS
– HTTP
– FTP
-SFTP
-SCP
– NFS
– SMB
در ضمن در نظر داشته باشید که از این دو پروتکل، فقط NFS 3 و SMB 2 پشتیبانی می شود.
قابلیتهای vCenter 6.7 Update 2
نکته اصلی اینه که نباید فقط از مدل File Level Backup استفاده کنید باید این مدل رو کنار Image Level Backup استفاده کنید.
دوباره بدانید این قابلیت ها فقط در VCSA موجود می باشند.
در این ورژن قابلیت Notification برای بک آپ و ریستور هم اضافه شده که میتوانید با استفاده از آلارم های موجود در vCenter از نحوه عملکرد بک آپ ها آگاه بشید.
vSphere Health
قابلیت هایی که Health در این ورژن بررسی می کند عبارتند از:
– Online Availability
– Compute
– Network
– Storage
که مجموع این موارد در بهبود کلی بستر بسیار کارا می باشند.
vSphere Plugins
در ورژن های قبلی vCenter یکی از مشکلات وحشتناک Troubleshoot مشکلات مربوط Plugins بودند.
در آپدیت 2 قابلیت مشاهده لاگ های مربوط به پلاگین ها بسیار راحت می باشد.
با استفاده از vSphere Client می تونید به منوی Administration و بعد زیر شاخه Solutions و درنهایت Client Plug-ins می تونید به راحتی لاگ های مربوط به پلاگین ها رو ببینید.
علاوه بر این در منوی Tasks می تونید جزییات مربوط به دانلود و رجیستر شدن موفق و غیر موفق تمامی پلاگین ها را مشاهده کنید.
گاهی اوقات ممکن است در شرایطی گرفتار بگیرید که مجبور شید از 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 باید بدانید در دهه اخیر سرعت محاسبات 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 ایجاد کرده است.
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 را تغییر دهیم؛
برای این منظور میتوان از پارامترهای زیر جهت تغییر رفتار پیش فرض استفاده کنیم (هر چند این کار توصیه شده نیست، مگر اینکه آگاهی کامل از نتیجه کار داشته باشید!).
numa.vcpu.min
به صورت پیش فرض -vNUMA- تنها برای ماشینهایی ایجاد خواهد شد که یکی از شرایط زیر را داشته باشند:
* ماشینهایی که تعداد vCPUهای آنها 9 یا بیشتر باشد.
* زمانی که تعداد vCPUهای ماشین مجازی بیشتر از تعداد Coreهای یک CPU Package باشد. گفتیم که این شمارش فقط تعداد Coreهای فیزیکی را در نظر خواهد گرفت نه Logical Processorها را!
با استفاده از این تنظیم میتوان این حداقل، یعنی عدد 9 را تغییر داد، تا برای ماشینهایی با vCPU کمتر نیز vNUMA ساخته شود.
numa.vcpu.maxPerMachineNode
ممکن است برنامهای داشته باشیم که حساس به Memory Bandwidth باشد نه Memory Access Latency! در چنین شرایطی حالت بهینه، بر خلاف حالت پیش فرض این خواهد بود که ماشین مجازی روی NUMA Nodeهای بیشتری توزیع شود تا پهنای باند بیشتری برای دسترسی به Memory داشته باشد.
این تنظیم به ما اجازه میدهد حداکثر تعداد vCPUهایی که داخل یک NUMA Client قرار خواهند گرفت را تغییر دهیم تا NUMA Clientهای بیشتری ساخته شود.
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).
اگر این تنظیم را برای یک ماشین که قبلاً یکبار روشن شده است، اعمال کنیم، بنا به دلائلی که پیشتر گفته شد، تاثیری نخواهد داشت و نیاز به استفاده از تنظیمات تکمیلی دیگری خواهد بود.
Cores per Socket
تنظیم Core per Socket (GUI) یا cpuid.coresPerSocket (Advanced Settings) به صورت پیش فرض روی عدد یک تنظیم شده است.
تغییر مقدار پیش فرض و افزایش آن باعث خواهد شد که -vNUMA- مستقیماً ساخته شده و در اختیار VM قرار گیرد که لزوماً ممکن است بهینه نباشد.
البته از نسخه 6.5 به بعد، این تنظیم دیگر تاثیری در رفتار vNUMA نخواهد داشت و vNUMA تحت هر شرایطی حالت بهینه را در اختیار Guest OS قرار خواهد داد.
چگونه به معماری vNUMA دسترسی داشته باشیم؟
در داخل فایل VMware.log هر ماشین مجازی اطلاعاتی در رابطه با معماری و ساختار vNUMA وجود دارد. اما به جای دانلود و بررسی خط به خط این فایل میتوان از دستور زیر استفاده کرد:
در تاریخ 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 فعال باشد، بیشتر از پیش مشکل ساز خواهد شد.
به طور کلی دو نوع خطر برای این آسیب پذیری متصور خواهد بود:
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 تست و اعلام شده است.
Performance Degradation
after applying patch
Application Workload / Guest OS
3%
Database OLTP / Windows
3%
Database OLTP / Linux
1%
Mixed Workload / Linux
<1%
Java / Linux
3%
VDI / Windows
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% خواهد بود (شخصاً اعتقاد چندانی به صداقت این عدد ندارم!). دو جدول زیر خلاصهای از نتایج مربوط به این آزمایشات را نمایش میدهد.
Performance Degradation after enabling the ESXi SCA Scheduler
Remaining usable Host CPU Capacity before enabling ESXi SCA Scheduler
% Host CPU Utilization before Enabling the ESXi SCA Scheduler
Application Workload / Guest OS
32%
0%
90%
OLTP Database / Linux
20%
~15%
77%
1%
~30%
62%
Performance degradation after enabling the ESXi Side-Channel-Aware Scheduler
Application Workload / Guest OS
32%
Database OLTP / Windows
32%
Database OLTP / Linux (with vSAN)
25%
Mixed Workload / Linux
22%
Java / Linux
30%
VDI / Windows
اگر در محیط مجازی شما یکی از شرایط لیست زیر برقرار باشد، احتمالاً با فعال سازی 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 به بعد بخونید :
اون چیزی که بالا راجع بهش صحبت کردیم 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 به ماشین مجازی در سروری با مشخصات زیر رو نشون میده :
همانطور که میدونیم بستر مجازی سازی سرور شرکت 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 ها مطالعه کنید چون بازارش خیلی داره داغ میشه.