منظور از استفاده از قابلیت های Windows Server Failover Clustering در محیط مجازی چیست؟ یکی دیگر از کاربردهای متداول RDMها برای پیکربندی‌های Windows Server Failover Clustering یا WSFC است، هرچند اکنون که مایکروسافت سرویس‌هایی مثل MS Exchange Database Availability Groups و MS SQL Server AlwaysOn Availability Groups را ارائه می‌دهد که الزام دستگاه‌های Quorum اشتراکی را نفی می‌کنند، میزان استفاده از این پیکربندی‌ها کمتر شده است.
WSFC می‌تواند در یک vSphere Host واحد، کلاستر در یک Box؛ کلاسترهای بین ماشین‌های مجازی روی vSphere Hostها، کلاستر در چندین Box، یا کلاسترها روی ماشین‌های مجازی و فیزیکی از کلاسترها استفاده کند. هر یک از این سناریوها برای Storage اشتراکی الزامات متفاوتی دارد که در جدول زیر خلاصه شده‌اند.
استفاده از WSFC در یک محیط مجازی نیازمند یک دیسک برای هر Node است که LEهای مخصوص به آن Node در دیسک ذخیره می‌گردند، LEهای دیگر نیازمند دسترسی اشتراکی برای دیسک Quorum هستند. آن دیسک‌ها باید از دسترسی سیستم LE به‌صورت Native پشتیبانی کنند که نیازمند استفاده از RDMها در حالت تطبیق‌پذیری فیزیکی است. این مثال دیگری است که منظور ما از استفاده از قابلیت های Windows Server Failover Clustering در محیط مجازی چیست؟ باید گفت RDMها راهکار منعطف‌تری را برای استفاده از تکنولوژی مجازی‌سازی فراهم می‌کنند.
| کلاستر در یک Box | کلاستر در چندین Box | N+1 Clustering | |
| دیسک‌های مجازی (VMDKها) | بله | نه | نه |
| Pass-through RDM (حالت تطبیق‌پذیری فیزیکی) | نه | بله | بله |
| Non-pass-through RDM (حالت تطبیق‌پذیری مجازی) | بله | بله | نه |
زمان و نحوه‌ی استفاده از Disk Spanning
معمولاً بهتر است که با یک LUN واحد در یک VMFS Volume شروع کنیم. برای افزایش اندازه‌ی آن Pool منابع، می‌توان از یکی از راه‌های زیر ظرفیت بیشتری را فراهم کرد:
1) اضافه کردن Extent جدیدی از VMFS به VMFS Volume
2) افزایش اندازه‌ی VMFS Volume روی LUN زیرین که در Array گسترش یافته باشد (از طریق توسعه‌ی پویا در Storage Array)
جهت مشاوره رایگان و یا راه اندازی زیرساخت مجازی سازی دیتاسنتر با کارشناسان شرکت APK تماس بگیرید. |
اضافه کردن Extent جدیدی از VMFS به VMFS Volume موجود منجر به Spanning یا توسعه‌ی VMFS Volume موجود روی بیش از یک LUN می‌شود. بااین‌حال تا وقتی که ظرفیت اولیه تکمیل شود، تخصیص اضافه‌ی ظرفیت مورد استفاده قرار نخواهد گرفت. وقتی بیش از یک LUN به یک VMFS Volume به‌خصوص اختصاص داده شود، VMFS روی LUNها I/O را Stripe نمی‌کند. همچنین توسعه‌ی VMFS Volume روی یک LUN موجود و بزرگ‌تر، اندازه‌ی VMFS Volume را افزایش می‌دهد اما نباید با Spanning اشتباه گرفته شود. بااین‌وجود، ویژگی VMFS Volume Grow را می‌توان مورد استفاده قرار داد تا یک VMFS Volume که روی چندین Extent از VMFS توسعه می‌یابد، علاوه بر VMFS Volumeی که روی چندین LUN توسعه می‌یابد گسترش پیدا کند، به شرط اینکه روی آن LUNها فضای کافی برای توسعه‌ی Extentهای VMFS وجود داشته باشد.
از دیدگاه مدیریتی ترجیح بر این است که یک LUN واحد و بزرگ با یک Extent واحد VMFS را Host کند. استفاده از چندین LUN برای پشتیبانی از چندین Extent از یک VMFS Volume شامل ارائه‌ی هر LUN به یکی از vSphere Hostها است که Datastore را به اشتراک می‌گذارند. با اینکه شاید پیش از انتشار vSphere 5 و VMFS5 به چندین Extent نیاز بود تا VMFS Volumeهای بزرگ‌تر از 2TB ایجاد گردد، VMFS5 و نسخه‌های جدیدتر آن از Volumeها با یک Extent تا حداکثر 64TB پشتیبانی می‌کنند.
کسب توان عملیاتی و ظرفیت Storage بیشتر
ظرفیت اضافه با Disk Spanning لزوماً ظرفیت توان عملیاتی I/O را برای آن VMFS Volume افزایش نمی‌دهد، اما منجر به افزایش ظرفیت Storage می‌شود. اگر ظرفیت اضافی به درستی روی Storage Array زیرین آماده‌سازی گردد، می‌توان آن را روی LUNهایی به غیر از LUN اول تخصیص داد و همچنین منجر به توان عملیاتی بیشتر می‌گردد. بسیار مهم است که مطمئن باشیم در هنگام اضافه کردن به یک VMFS Volume موجود، LUNهایی با عملکرد مشابه را اضافه می‌کنیم (سرویس‌های داده و چگالی I/O).
محدودیت اندازه برای یک VMFS6 درحال‌حاضر 64TB بوده و در VMFS3، اندازه‌ی Extent ،2TB می باشد. برای Volumeهای VMFS3 جهت متمرکز ساختن چندین 2TB Extent، به Spanning نیازاست. محدودیت 32 Extent در VMFS Volume وجود دارد و حد اندازه‌ی هر VMFS Volume ،64TB می باشد. Spanning چندین Volume یا LUN برای رسیدن به حد بالایی مورد نیاز بود و اکنون برای هر VMFS3 Volume بزرگ‌تر از 2TB مورد نیاز است. این امر برای VMFS5 یا نسخه‌های جدیدتر آن ضروری نیست، زیرا یک Extent واحد از VMFS Volume را می‌توان با این نسخه‌های جدیدتر ایجاد کرد.
بیشتر بخوانید: vSphere Storage DRS چیست؟ معرفی و بررسی آن
پیشنهادهایی برای اسکن مجدد: در نسخه‌های قبلی از vSphere، پیشنهاد می‌شد که پیش از اضافه کردن یک VMFS Extent به یک VMFS Volume، اطمینان حاصل شود که یک اسکن مجدد از SAN برای تمام Nodeها در کلاستری که Pool مشترکی از Storage را به اشتراک می‌گذارد، اجرا گردد. اما در نسخه‌های جدیدتری از vSphere، یک اسکن مجدد خودکار وجود دارد که وقتی هدف یک LUN جدید را شناسایی می‌کند فعال می‌گردد تا هر vSphere Host بتواند وقتی که تغییری روی منبع Storage اشتراکی خود به وجود می‌آید، آن را بروزرسانی کند. این اسکن مجدد خودکار، تنظیم پیش‌فرضی در vSphere است و پیکربندی می‌گردد تا هر 300 ثانیه تغییر کند.
نگاه دقیق‌تری به بهبود‌های VMFS6
در بررسی قابلیت های Windows Server Failover Clustering در محیط مجازی باید گفت با انتشار vSphere 6.5، نسخه‌ی جدیدی از VMFS منتشر شد. VMFS6 دارای تعدادی از بهبودها و پیشرفت‌های جدید است که در اینجا در موردشان صحبت می‌شود.
Blockهای فایل کوچک و Blockهای فایل بزرگ: VMFS6دارای دو اندازه‌ی Block، داخلی، یک File Block کوچک یا SFB و یک File Block بزرگ یا LFB است. نباید این اندازه را با اندازه‌ی Block واقعی که روی VMFS6 مورد استفاده قرار می‌گیرد اشتباه گرفت؛ این اندازه هنوز 1MB است. SFBو LFB برای پشتیبانی از فایل‌هایی که روی VMFS ایجاد می‌شوند، مورد استفاده قرار می‌گیرند. SFB به 1MB و LFB به 512MB تنظیم می‌گردد.
وقتی فایل‌های Thin روی VMFS6 ایجاد می‌گردند، در ابتدا توسط SFBها پشتیبانی می‌شوند. فایل‌های Thick که روی VMFS6 ایجاد می‌گردند، وقتی که ممکن باشد، توسط LFBهای پشتیبانی می‌گردند. مثلاً اگر یک VMDK، Lazy Zeroed Thick یا همان LZT یا Eager Zeroed Thick یا همان EZT باشد، این VMDK همیشه از LFBها استفاده می‌کند، به شرطی که برای تخصیص قابل‌دسترسی باشند. اگر بخشی از فایل Thick وجود داشته باشد که یک LFB را Overflow کند، بخش باقی مانده توسط SFBها پشتیبانی می‌گردد.
این بهبود به VMFS6 باید منجر شود به زمان ساخت فایل بسیار سریع‌تر، مخصوصاً برای فایل‌های Thickشده، این امر همچنین زمان روشن شدن را برای VMها بهبود می‌بخشد. وقتی که یک VM روشن می‌شود، یک فایل Swap ایجاد می‌گردد. این فایل Swap همیشه Thick است، پس اگر فایل Swap توسط LFBها پشتیبانی گردد، باید بسیار سریع‌تر ایجاد شود.
فایل‌های منبع سیستم پویا
فایل‌های منبع سیستم (.fdc.sf، .pbc.sf، .sbc.sf، .jbc.sf) اکنون به‌صورت پویا برای VMFS-6 توسعه پیدا می‌کنند. هدف این است که Volumeهای VMFS6 را بتوان ایجاد نمود که ظرفیت کوچکی دارند. دلیل دیگر این رویکرد این است که روی حداکثر ظرفیت Volume با اندازه‌ی Formatting ابتدایی‌اش محدودیتی قرار گیرد، بلکه اجازه داده شود که به‌طور پویا در طول زمان رشد کند. اگر فایل سیستم هر منبعی را تمام کند، فایل منبع سیستم مربوطه گسترش پیدا می‌کند تا منابع بیشتری ایجاد گردد. VMFS-6 اکنون می‌تواند از میلیون‌ها فایل به شرط اینکه Volume فضای خالی داشته باشد پشتیبانی کند.
فایل منبع سیستم Journal جدید
VMFS6 یک فایل سیستم Journaling توزیعی بوده و پیش از ایجاد تغییر در هر یک از فایل‌های روی Volume، یک مدخل Journal ایجاد می‌شود تا اگر عملیات به هر دلیلی دچار خرابی شود از ان استفاده شود. پیش از VMFS-6، مدخل‌های Journal از File Blockهای عادی استفاده می‌کردند، این امر منجر به مشکلات عملیاتی، مثلاً در مورد یک فایل سیستم کامل می‌شد. آسان‌ترین راه برای حل چنین شرایطی حذف برخی از فایل‌هامی باش، اما این امر به ایجاد یک مدخل Journal روی VMFS نیازمند است. ازآنجایی‌که هیچ File Blockی برای ایجاد مدخل Journal قابل دسترسی نیست، لازم بود که کاربران مراحلی اضافی را طی کنند تا مقداری فضا آزاد نمایند.
