معرفی، نصب و راه اندازی vSAN

معرفی قابلیت vSAN

شرکت VMware برای ارائه راهکار Hyper-Converged مربوط به خود، قابلیت vSAN را ارائه داده است که یک Software-define storage است. با استفاده از این قابلیت می‌توانیم از تمامی دیسک‌های داخلی سرورها که در اصطلاح DAS نامیده می‌شوند، به عنوان SAN Storage استفاده کنیم. در نتیجه دیگر نیاز به خرید استوریج مجزا برای ذخیره سازی نیست و هزینه‌های سازمان تا حد زیادی کاهش پیدا می‌کند.

قابلیت vSAN از نسخه ۵.۵ مجموعه VSphere به این محصول اضافه شده است و با معرفی این راهکار تحول بسیار شگفت‌انگیزی در حوزه ذخیره سازی داده‌ها در تکنیک Software Defined Storage ایجاد شده است. در واقع vSAN یک تکنولوژی Software Defined Storage است که به معنی مستقل بودن از لایه سخت افزار است، هرگاه شما در شبکه، دارای دیسک‌های متعددی به‌صورت لوکال بودید و می‌خواستید همه آن‌ها را در قالب یک مجموعه مدیریت شده استفاده کنید راهکار vSAN به شما کمک می‌کند.

 

این قابلیت به‌صورت مستقیم در خود هایپروایزر قرار گرفته است و به‌صورت ماژول یا قابلیت جدید، نیازی به نصب شدن ندارد. برای راه‌اندازی یک vSAN در vCenter یک VMKernel NIC ایجاد کرده و در سطح کلاستر قابلیت vSAN را فعال می‌کنید. با فعال کردن vSAN تمامی قابلیت‌های VMware مانند DRS، HA و vMotion که برای استفاده، نیاز به shared storage دارند نیز قابل استفاده خواهند بود.

برای مثال تصور کنید که در یک سازمان ۵ عدد سرور داریم که بر روی هر کدام از آن‌ها تعداد ۲ عدد هارددیسک وجود دارد که دارای ظرفیت ۱ ترابایت هستند، این ۲ عدد هارددیسک به‌صورت RAID شده توسط هاست به عنوان Datastore استفاده می‌شوند. در این شبکه ما هیچ‌گونه تجهیزات ذخیره سازی مانند SAN یا NAS در اختیار نداریم اما در عوض بر روی هر عدد از سرورها ۲ عدد هارددیسک داریم به ظرفیت ۲ ترابایت که در مجموع همۀ سرورها ظرفیتی بالغ بر ۱۰ ترابایت را در اختیار ما گذاشته است که در حالت عادی فقط توسط همان هاست قابل استفاده است و در شبکه قابل استفاده نیست. در چنین مواقعی است که ما تصمیم می‌گیریم از قابلیت vSAN برای مدیریت کردن این هارددیسک‌ها و تبدیل کردن آن‌ها به یک SAN Storage مجازی اقدام کنیم، کاری که vSAN برای ما انجام می‌دهد این است که تمامی این هارددیسک‌های اضافی را مدیریت می‌کند و درنهایت در قالب یک مجموعه مجازی و یکپارچه در اختیار شما قرار می‌دهد. در چنین حالتی انگار شما در شبکه، SAN Storage واقعی از دید هاست‌ها دارید با این تفاوت که اطلاعات بر روی هارددیسک‌های هاست‌های مختلف توزیع شده است ولی امکانات شما در عین حال افزایش یافته است.

البته باید در نظر داشته باشید که یک اصطلاح VSAN نیز در مبحث FC Switch ها داریم که به هیچ‌وجه با این موضوع در ارتباط نمی‌باشد. عموماً نحوۀ نوشتاری این دو از لحاظ بزرگی و کوچکی حروف با هم متفاوت می‌باشند. vSAN – VSAN

محدودیت‌ها و قابلیت‌های موجود در vSAN

•  هر سرور را تنها می‌توانید در یک vSAN cluster عضو نمایید و نه بیشتر، اما در عین حال می‌توانید در یک کلاستر چندین vSAN داشته باشید.
•  در vSAN نمی‌توانید دیسک‌های بزرگ‌تر از ۲ ترابایت برای ماشین‌های مجازی خود ایجاد نمایید.
• در vSAN تنها دیسک‌های SATA، SAS و PCIe پشتیبانی می‌شوند و سایر انواع استوریج مانند FC، iSCSI و USB پشتیبانی نمی‌شوند.
•  قابلیت‌هایی مانند FT و DPM در vSAN پشتیبانی نمی‌گردند.
•  برای راه‌اندازی vSAN حداقل نیاز به ۳ عدد سرور است. البته از vSAN نسخه ۶.۱ راهکار دو سرور نیز اضافه گردید که در ادامه توضیح داده خواهد شد.
• در vSAN هر سرور باید دستکم یک دیسک SSD و یک دیسک HDD داشته باشد. در واقع از دیسک HDD برای ساخت فضای datastore و از دیسک SSD برای ساخت فضای Cache استفاده می‌گردد.

نکته: شما می‌توانید در vCenter یک دیسک ssd را تگ capacity tier بزنید تا به عنوان دیسک hdd شناخته شود و یا حتی برعکس، می‌توانید یک دیسک hdd را تگ flash disk بزنید تا به عنوان دیسک ssd و برای کش استفاده شود و از این طریق این محدودیت را از بین ببرید.

• تنها دیسک‌های DAS و لوکال می‌توانند در vSAN شرکت کنند و به هیچ‌وجه نمی‌توان از استوریج‌های SAN یا NAS حتی اگر به کلاستر متصل باشند، استفاده کرد.
•  قابلیت vSAN کنترل تمام دیسک را در اختیار خود می‌گیرد و آن را با قابلیت‌های دیگر به اشتراک نمی‌گذارد.
• در vSAN یک datastore ساخته می‌شود که قابل دسترسی توسط تمام سرورهای کلاستر است، حتی اگر دیسک‌های یک سرور در آن vSAN شرکت داده نشده باشند. همچنین تمام سرورها می‌توانند علاوه بر دیتا استور vSAN، سایر انواع استوریج مانند SAN و NAS را نیز داشته باشند.
• اگر در یک vCenter چند vSAN cluster دارید، هر کلاستر datastore مربوط به خود را خواهد داشت و شما می‌توانید با استفاده از vMotion ماشین‌های مجازی خود را بین این vSAN datastore ها جابه‌جا نمایید.
• تنها فضای دیسک‌های HDD در این نوع از datastore شرکت می‌کنند و فضای دیسک‌های SSD به عنوان قسمتی از دیتااستور شمرده نمی‌شوند. به عبارت دیگر از دیسک‌های ssd به‌دلیل IOPS بسیار بالا، به عنوان cache استفاده می‌گردد.

نکته: در حالتی که تمام دیسک‌های سرورها از نوع ssd باشند، در واقع All-Flash vSAN خواهیم داشت. در vSAN نسخه ۶ این قابلیت ایجاد شده است که بتوانید بر روی دیسک‌های SSD تگ Capacity tier بزنید تا از این طریق امکان شرکت دادن فضای این دیسک‌ها در دیتااستور نیز فراهم گردد.

• اگر vSAN را در حالت automatic پیکربندی نمایید، با اضافه کردن سرور به vSAN cluster و یا اضافه کردن دیسک به سرورهای موجود، فضای datastore به‌صورت اتوماتیک افزایش می‌یابد.
• برای vSAN می‌بایست حداقل یک لینک فیزیکی ۱G برای این کار اختصاص داد و یک VMKernel port group ساخته و قابلیت vSAN را در آن فعال نمایید.
• عملیات ساخت RAID توسط vSAN انجام می‌شود و به همین دلیل نباید از طریق سرور اقدام به ساخت RAID کرد.

انواع معماری‌ها در راه اندازی vSAN

همان‌طور که گفته شد وجود ۳ سرور، یکی از قوانین راه اندازی vSAN است. یکی از این سرورها در نقش witness است که وجود آن الزامی است زیرا مانع از بوجود آمدن split brain می‌شود. برای فهم بیشتر این مطلب می‌بایست با نحوه عملکرد vSAN بیشتر آشنا شویم.

در ابتدا باید بدانیم که vSAN بر مبنای object کار می‌کند. هر کدام از آیتم‌هایی که یک ماشین مجازی را تشکیل می‌دهند، یک object به حساب می‌آیند. مثلاً یک فایل vmdk، یک دیسک دلتا یا همان اسنپ شات، فایل swap و غیره که هر کدام یک object می‌باشند. یکی از ویژگی‌های منحصربه‌فرد vSAN دستیابی به high availability است، به‌شکلی که در صورت از کار افتادن یکی از سرورها، همچنان تمامی دیتای ما در دسترس باقی بماند. در این راهکار که با نام  Failures to Tolerate  نیز شناخته می‌شود، vSAN به هر سرور به شکل یک independent failure domain نگاه می‌کند و در نتیجه هر object را در هر دو سرور قرار داده تا مطمئن شود در صورت از کار افتادن هر سرور، همچنان تمامی دیتا در دسترس خواهد بود. برای اینکه یک object توسط vSAN قابل دسترس باشد باید بیش از ۵۰ درصد اجزای مرتبط با آن object در دسترس باشد. حال برای مثال دیسک یک ماشین مجازی را در نظر بگیرید. یک نسخه اصلی دیتای آن در سرور اول، نسخه دوم دیتا در سرور دوم و جزء witness آن در سرور سوم قرار گرفته است. برای اینکه این فایل در دسترس باشد باید بیش از ۵۰ درصد اجزا در دسترس باشند یعنی حداقل دو سرور از سه سرور می‌بایست موجود باشند. فرمول زیر برای زمانی که از Failures to tolerate = 1 و RAID 1 استفاده می‌کنیم برقرار است:

Esxi-02 witness (no data)  + Esxi-01 component (data) = 2/3  is  > 50%
Esxi-02 witness (no data)  + Esxi-03 component (data) = 2/3 is   > 50%
Esxi-01 component (data)  + Esxi-03 component (data) = 2/3 is  > 50%

برای Failures to tolerate = 2 و RAID 1 باید ۵ سرور داشته باشیم که سه تای آن component و دو عدد witness هستند. همچنین برای Failures to tolerate = 3 و RAID 1 باید ۷ سرور داشته باشیم که ۴ تای آن component و ۳ عدد witness هستند.

برای اینکه یک ماشین مجازی بتواند درست تشخیص بدهد که در زمان از دسترس خارج شدن سرور و برگشت مجدد آن، دیسک خود را از کجا باید بخواند که مشکلی ایجاد نگردد، می‌بایست از یک سرور سومی استفاده کرد که در واقع از این split brain احتمالی جلوگیری نماید.

از vSAN نسخه ۶.۱، قابلیت راهکار دو عدد سرور نیز در این معماری گنجانده شد که برای کاهش هزینه‌های سازمان در عین حال که availability نیز قربانی نشود، بسیار کارائی دارد. در این راهکار دیگر نیازی نیست که حتما یک سرور اختصاصی به عنوان witness در همان کلاستر قرار دهیم. بلکه می‌توانیم از appliance مربوط به اینکار به‌صورت یک ماشین مجازی استفاده نماییم که می‌تواند خارج از کلاستر باشد، مثلاً بر روی یک سرویس cloud. این appliance به‌صورت یک nested ESXi عمل می‌کند یعنی انگار که یک esxi بر روی esxi اصلی نصب کرده‌ایم. در Witness Appliance تنها witness objects و cluster metadata ذخیره می‌شود و دیتای اصلی بر روی آن کپی نمی‌شود. این appliance به‌صورت فایل OVA است که حداکثر منابعی که احتیاج دارد ۲ هسته cpu و ۸ گیگ حافظه است و برای راه‌اندازی، نیازی به هیچ پیکربندی خاصی ندارد. برای تعیین فضای دیسک نیز باید در نظر داشته باشید که هر object به ۱۶ مگابایت فضا نیاز دارد که با توجه به تعداد ماشین‌های مجازی خود می‌توانید میزان فضا را تعیین نمایید. برای مثال یک ماشین مجازی حداقل سه object برای vmdk، namespace و swap دارد و هر اسنپ شات نیز یک object اضافه می‌کند. پس به راحتی می‌توانید تخمینی برای میزان فضای لازم بزنید.

تا اینجای کار ما توانستیم با استفاده از vSAN یک shared storage برای سرورها بسازیم. اما زمانی که یک سرور از مدار خارج می‌شود علاوه بر استوریج نیاز است که پردازش ماشین‌های موجود در آن سرور نیز به ماشین دیگر منتقل گردد. برای اینکار نیز باید از سرویس HA استفاده نماییم که می‌تواند به‌صورت اتوماتیک آن ماشین‌ها را در سرور دیگر restart نماید.

لازم است که بدانید اگر به هر دلیل vCenter از مدار خارج شود، vSAN همچنان به کار خود ادامه می‌دهد ولی تا برگشت آن، دیگر نمی‌توانید اقدام به تغییر تنظیمات مدیریتی نمایید.

 

امیر باقری – تیر ۹۹

 

پرسش و پاسخ

آیا برای راه اندازی vSAN به vCenter نیاز است؟

برای پیکربندی و مدیریت کلاستر vSAN نیاز به vCenter است و نمی‌توانید بدون آن اقدام به نصب vSAN نمایید.

آیا در صورت خارج شدن vCenter از مدار، vSAN نیز عمل نخواهد کرد؟

خیر اینگونه نیست و زمانی که به هر دلیلی vCenter از مدار خارج شود، vSAN به کار خود ادامه می‌دهد ولی دیگر نمی‌توانید تا برگشت آن، اقدام به پیکربندی vSAN نمایید.

آیا vSAN یک نمونه از معماری HCI است؟

بله vSAN یک راهکار SDS برای زیرساخت‌های فوق همگرا یا HCI است.

حداقل چه تعداد هاست برای راه اندازی vSAN نیاز است؟

برای راه اندازی vSAN حداقل نیاز به ۳ عدد هاست وجود دارد. هرچند که از نسخه ۶.۱ شما می‌توانید با ۲ هاست نیز این کار را انجام دهید.