Skip to Content

آرشیو دسته بندی ها:دسته‌بندی نشده

بررسی VMware vSphere Virtual Volumes یا VVOLs – قسمت دوم

بررسی VMware vSphere Virtual Volumes یا VVOLs – قسمت دوم

Virtual Volume چیست

در قسمت اول از سری مقالات VMware VVOLs، به بررسی قابلیت‌های این تکنولوژی پرداختیم. در این مقاله که قسمت دوم (پایانی) می‌باشد به بررسی مزایای این تکنولوژی می‌پردازیم.

مزایای تکنولوژی vSphere Virtual Volume

Virtual Volume در حوزه‌ها‌ی عملیات ذخیره‌سازی، ارائه سطح سرویس و کاربرد منابع دارای مزایای ارزشمندی می‌باشد.

ساده‌سازی عملیات ذخیره‌سازی

این تکنولوژی موجب سهولت قابل توجهی در روند مدیریت مدل‌های‌ عملیاتی فعلی برای Admin vSphere و Storage Admin می‌شود؛ به علاوه، امکان تفکیک فرآیند آماده‌سازی و کاربرد Storage برای ماشین‌های مجازی را فراهم می‌نماید.

Virtual Volume چیست

تفکیک فرآیند آماده‌سازی و کاربرد Storage

Storage Admin در مدل ذخیره‌سازی مبتنی بر نرم‌افزار (Software-Defined Storage) شرکت VMware همراه با Virtual Volume، به ایجاد Storage Container می‌پردازند. سرویس‌های داده و ظرفیت به وسیله‌ی Storage Admin از Storage Array انتشار می‌یابد و در Storage Container به صورت آیتم‌هایی در می‌آیند که vSphere Adminn می‌تواند در صورت نیاز از آن‌ها استفاده نماید.

Storage Admin این قابلیت را داراست که کنترل منابع ذخیره‌سازی را در اختیار داشته باشد، در حالیکه vSphere Administrator صرفا می‌تواند از قابلیت‌های ارائه شده‌ در Storage Array، استفاده نماید. اگرچه نیازی نیست که Storage Admin مشخص کند کدام یک از سرویس‌های داده باید به یک برنامه اختصاص یابند. بنابراین  Storage Admin باید مسئولیت تنظیمات اولیه را به عهده بگیرد اما vSphere Admin به صورت Self-Sufficient می‌باشد و وظیفه انجام کار‌های بعدی را دارد.

مدیران vSphere با استفاده از Virtual Volume قادرند کنترل امور را در اختیار گرفته و مسئولیت تعریف سطوح مختلف سرویس را برای برنامه به عهده گیرند. اگرچه سطح سرویس‌ها دیگر به صورت فیزیکی و از پیش اختصاص یافته نبوده و یک سری موجودیت منطقی می‌باشند که به طور کامل توسط نرم‌افزار کنترل و خودکارسازی شده و با مکانیسم Policyyها تفسیر می‌گردند.

در صورت مرتبط شدن یک یا چند ماشین مجازی به یک Policy به نحوی درست، آماده‌سازی و نمونه‌سازی واقعی از سطح سرویس Storage برای یک یا مجموعه‌ای از ماشین‌های مجازی، خودکارسازی می‌گردد. همچنین اجرای خودکار Policy به مکانیسمی برای ساده‌سازی فرآیند مانیتورینگ و تضمین فرآیند تطبیق سطوح سرویس Storage در تمامی چرخه عمر برنامه تبدیل می‌شود.

خودکارسازی مبتنی بر Policy، امکان استفاده سریع‌تر از Storage برای ماشین‌های مجازی را فراهم می‌نماید که در نهایت موجب آماده‌سازی سریع‌تر برای برنامه‌های جدید همراه با شرایط مختلف و تسهیل فرآیند مدیریت تغییرات می‌گردد؛ این در حالی است که vSphere Admin می‌تواند در هر زمانی تغییراتی را در Policy‌ها اعمال نموده و تغییرات ضروری زیرساخت را از طریق خودکارسازی، پیکربندی نماید. بدین ترتیب امکان انطباق سریع‌تر با تغییرات بروزیافته در کسب‌وکار فراهم می‌گردد.

Storage Admin وضعیت فعلی با Virtual Volume مزایا
آماده‌سازی Datastore تعداد زیادی از Policyهای استاندارد مبتنی بر LUN که هر یک مختص یکی از برنامه‌ها می‌باشد.مدیریت ظرفیت ممکن است مرتبط به LUN باشد.

به فرمت VMFS نیاز دارد.

تعداد کمی Datastore نیاز است اما نیاز به اشتراک‌گذاری دارد. برنامه‌ریزی ظرفیت بر روی یک Pool است. قابلیت‌هایی را تعریف می‌کند تا بدون محدودیت‌های Static به کار برده شود.ابزارهای مدیریت Vendorها نیاز زیادی به بروزرسانی دارند.
عیب‌یابی و مانیتورینگ Key off از Datastore مبتنی بر VM/VMDK است آگاهی و اطلاعات در مورد ماشین مجازی در سیستم‌های ذخیره‌سازیابزارهای مدیریت Vendorها، نیاز زیادی به بروزرسانی دارند.
آماده‌سازی برای Datastoreهایی با استفاده از Policyهای مبتنی بر Tag برای Datastoreها با Policy‌های توسعه پذیر و توانایی تغییر پویای آنها کاربرد Storage خودکارسازی شده است.نیازی به طراحی ماشین‌های مجازی برای LUNها نمی‌باشد.
عیب‌یابی و مانیتورینگ داشتن   Datastore به ازای هر ماشین مجازی موجب ایجاد فرآیند دستی می‌شود تا انطباق Policyها را تضمین نماید. Per-VM VendorContainer موجب خودکارسازی فرآیند انطباق مانیتورینگ Policy‌ها می‌شود.

 

آگاهی و اطلاعات در مورد ماشین مجازی در سیستم‌های ذخیره‌سازی و دیدگاه انطباق PolicyVMware Tools را می‌توان با Virtual Volume به گونه‌ای بهتر ارائه نمود.

 شرایط Storage جهت استفاده از Virtual Volume

Virtual Volume نیاز به یک سیستم سازگار با Storage Array دارد. در اغلب موارد، یک راهکار نرم‌افزاری مانند Virtual Storage Appliance که از سوی یکی از Vendorهای پشتیبانی کننده، ارائه می‌شود برای تست جریان‌های کاریِ (Work Flow) مدیریت، عملیات‌ و عملکردها پشتیبانی می‌گردد.

البته بسته به نوع اجرا و پیاده‌سازی، سیستم Storage Array ممکن است برای پشتیبانی از VVOL نیاز به ارتقای Firmware داشته باشد.

لازم به ذکر است جدیدترین نسخه vSphere 6.0 برای استفاده از vSphere Virtual Volume مورد نیاز می‌باشد. این نرم‌افزار و تمام اجزای مربوط به آن در وب‌سایت شرکت VMwaree به طور مستقیم جهت دانلود در دسترس می‌باشد.

ــــــــــــــــــــــــــــــــــــــــــــــ

بررسی VMware vSphere Virtual Volumes یا VVOLs – قسمت اول

بررسی VMware vSphere Virtual Volumes یا VVOLs قسمت دوم (پایانی)

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

ادامه مطلب

بررسی VMware vSphere Virtual Volumes یا VVOLs – قسمت اول

بررسی VMware vSphere Virtual Volumes یا VVOLs – قسمت اول

Virtual Volume چیست

Virtual Volumes از چارچوب‌های جدید مدیریت و یکپارچه‌سازی دیسک‌های ماشین مجازی به شمار می‌رود که این دیسک‌ها را به عنوان واحد اصلیِ مدیریت داده‌ها برای Storage Arrayyها ارائه می‌نماید. با کمک این چارچوب جدید می‌توان عملیات‌های مبتنی بر Array را در سطح دیسک مجازی فعال نمود که این موضوع دقیقا قابل انطباق با محدودیت‌های برنامه کاربردی می‌باشد. Virtual Volume متشکل از دو پیاده‌سازی مهم می‌باشد:

کاربرد قابل انعطاف در سطح منطقی

Virtual Volumes یا به اختصار VVOLs، مجازی‌سازی تجهیزات SAN و NAS را از طریق تعریف منابع سخت‌افزاری فیزیکی به صورت Poolهای ظرفیت منطقی (که در vSphere به عنوان Datastore مجازی شناخته می‌شوند) صورت می‌دهند؛ این ظرفیت را می‌توان به گونه‌ای انعطاف‌پذیر برای توسعه بخشی از یک یا چند Storage Array استفاده و پیکربندی نمود.

Virtual Datastore به تعریف محدودیت‌های موجود در ظرفیت و تعیین دسترسی‌های منطقی (Access Logic) پرداخته و مجموعه‌ای از سرویس‌های قابل دسترس برای ماشین‌های مجازی آماده شده در Pool را ارائه می‌نماید. Virtual Datastoree یک ساختار منطقی می‌باشد که در هنگام نیاز، بلافاصله و بدون بروز قطعی پیکربندی می‌شود و نیازی به فرمت شدن با یک فایل سیستم را ندارد.

کنترل دقیق‌تر در سطح ماشین مجازی

Virtual Volumes به تعریف یک Container جدید برای دیسک مجازی می‌پردازد که مستقل از Storage فیزیکی (LUN, File System, Objectt) می‌باشد. به عبارتی دیسک مجازی با این تکنولوژی، به واحد اصلیِ مدیریت داده در هر سطح از آرایه تبدیل شده و بدین ترتیب، Virtual Datastore به یک ماشین مجازی میانی در Pool مربوطه تبدیل می‌شود.

به علاوه این امکان نیز وجود خواهد داشت که عملیات‌های ذخیره‌سازی با توسعه‌پذیری ماشین مجازی اجرا شود و سرویس‌های داده اصلی و مبتنی بر آرایه مانند فشرده‌سازی، Snapshot، Deduplication، رمزگذاری و سایر موارد برای هر یک از ماشین‌های مجازی آماده‌ گردد. بدین ترتیب مدیران می‌توانند سطح مطلوبی از سرویس‌های ذخیره‌سازی را برای هر یک از ماشین‌های مجازی فراهم آورند. Virtual Volume به منظور ایجاد بهره‌وری در عملیات‌های ذخیره‌سازی حتی در هنگام مدیریت هزاران ماشین مجازی، از vSphere Storage Policy-Based Management یا به اختصار SPBM استفاده می‌نماید. SPBM، اجرای سطح کنترل بر اساس Policyy در مدل ذخیره‌سازی مبتنی بر نرم‌افزار VMwaree می‌باشد.

عملیات کارآمد از طریق خودکارسازی

SPBM، امکان دستیابی به الزامات سطح سرویس‌دهی برای Storage شامل ظرفیت، عملکرد، دسترس‌پذیری (Availability) و … را به صورت Template‌ها یا Policy‌های منطقی مرتبط با ماشین‌های مجازی فراهم می‌کند. SPBM با شناسایی Datastoreهای در دسترس و منطبق با Policyها و در کنار Virtual Volumes یا VVOLs می‌تواند روند جایگزینی ماشین‌های مجازی را خودکار نموده و سرویس‌های داده مورد نیاز را به صورت Dynamic ارائه ‌نماید. همچنین SPBM با اجرای Policy می‌تواند مانیتورینگ سطح سرویس و سازگاری را در طول چرخه عمر ماشین‌ مجازی خودکار ‌نماید.

هدف این تکنولوژی آن است که علاوه بر ارائه یک مدل عملیاتی ساده‌تر جهت مدیریت ماشین‌های مجازی در Storage خارجی، از یک مجموعه غنی از قابلیت‌های موجود در Storage Arrayها نیز بهره‌مند شود. VMware با این تکنولوژی به دنبال تبدیل یک مدل عملیاتی پایین به بالا که در آن ابتدا آماده‌سازی سخت‌افزار و سپس انطباق ماشین‌های مجازی با آن در بهترین حالت ممکن رخ دهد و یا یک مدل عملیاتی بالا به پایین که شرایط ماشین‌های مجازی در آن موجب آماده‌سازی Storage می‌شود، می‌باشد.

Virtual Volumes از طریق هم تراز کردن کاربرد و عملیات‌های Storage با ماشین‌های مجازی موجب تبدیل Data Plane و Control Plane در سیستم‌های ذخیره‌سازی پشتیبانی شده‌ی SAN و NASS می‌شود. این تکنولوژی با یک رویکرد مبتنی بر ماشین‌مجازی میانی در روند جداسازی یک دیسک مجازی واحد می‌تواند سیستم‌های ذخیره‌سازی پشتیبانی شده‌ی SAN و NAS را با VMware آشنا نموده و قابلیت بهره‌مندی از سرویس‌های داده مبتنی بر Array و قابلیت‌های Storage Array را ارائه نماید.

با این تکنولوژی، اکثر عملیات مانند Snapshot ،Cloning و Migration به Storage Array به صورت Offload انجام می‌شود. عملیات‌های جدید مدیریت و مانیتورینگ داده و مکانیسم‌های ارتباطی بدین منظور اجرا می‌شوند که ارتباطات ضروری بین vSphere، Storage Array و Virtual Volumes را مدیریت نمایند.

Virtual Volume چیست

تفاوت Storageهای قدیمی و Storageهای مبتنی بر نرم‌افزار یا SDS به همراه vSphere Virtual Volumes

در این مدل پیچیدگی مدیریت زیرساخت ذخیره‌سازی و سرویس‌های آن حذف شده و به صورت مستقل از کاربران ماشین‌های مجازی سرویس می‌دهد و یک Control Plane جدید (SPBM) ارائه می‌گردد که متمرکز بر ماشین‌های مجازی می‌باشد. هر یک از ماشین‌های مجازی صرفا آیتم‌های مورد نیاز را طبق چارچوب مدیریت متداول در سیستم‌های ذخیره‌سازی ناهمگون و متشکل از منابع مختلف را دریافت می‌کند.

در مدل قدیمی، باید برای هر ماشین مجازی یک Storage Tier از پیش تعریف شده و یک Storage Container از پیش پیکربندی شده (LUN/Volume) طراحی و برنامه‌ریزی شود؛ ضمن اینکه هر یک از ماشین‌های مجازی استقرار یافته در داخل این ساختارها برای خود سطحی متفاوت از سرویس را ارائه خواهند کرد. مدیریت Tierهای مختلف سرویس با استفاده از LUN یا Volume در مدل قدیمی متداول می‌باشد.

به عنوان مثال، Gold LUN نشان دهنده بالاترین سطح سرویس بوده و هر یک از ماشین‌های مجازی استقرار یافته در این LUN باید دارای سطح سرویس همین LUN باشند. شاید در بسیاری از موارد، یک LUN یا Volume با ترکیب درستی از ظرفیت و سطح سرویس Storage قابل دسترسی نباشد.

بنابراین این موضوع باعث می‌شود ماشین‌های مجازی بدون اینکه نیاز به تمام سرویس‌های تجهیز ذخیره‌سازی داشته باشد، در Gold LUN استقرار ‌یابند؛ این امر باعث پیچیدگی در مدیریت سرویس‌های داده‌ در تمامی ماشین‌های مجازی در Gold LUN می‌شود. شاید نیازی به Replicate شدن همه سیستم‌ها نباشد اما نه تنها به عنوان Gold LUN عمل Replication انجام می‌شود بلکه بالاترین سطح عملکرد را نیز به عنوان ویژگی مورد نیاز اکثر سیستم‌ها دارا می‌باشد؛ به علاوه اینکه هزینه عملیاتی مربوط به مدیریت این وابستگی‌های متقابل و هزینه‌های مالی مربوط به محصولات جانبی Overprovisioning یا مصرف بیش از حد پهنای باند نیز وجود خواهند داشت. بنابراین جابجایی از مدل‌های ذخیره‌سازی قدیمی به مدل Virtual Volumes ، شبیه به حرکت از یک مدل مصرف ثابت به یک مدل مصرف متغیر و متنوع است.

سیستم‌ها پس از آماده‌سازی اغلب شرایط را تغییر می‌دهند. شاید بارکاری (Workload) مورد نظر در یک فصل یا در پایان ماه دارای افزایش ناگهانی عملکرد باشد و یا یک سیستم کم اهمیت به مرور زمان در کاری، اهمیت یافته و حیاتی شود. در مدل ذخیره‌سازی سنتی نیاز به بررسی دقیق ظرفیت فعلی، مدیریت LUN، Storage  vMotion (که در مقالات قبلی سایت به آن پرداخته شد) و احتمالا آماده‌سازی مجدد برنامه برای دستیابی به شرایط و الزامات جدید وجود دارد.

با Virtual Volumes و SPBM می‌توان به راحتی یک سیاست جدید را به سیستم‌هایی که از قبل پیاده‌سازی شده‌اند، اختصاص داد؛ Array  به صورت خودکار سیستم را در موقعیتی قرار می‌دهد که مطابق با Policy جدید باشد یا اینکه Policy را در صورت نیاز و با توجه به شرایط پیاده‌سازی تغییر می‌دهد. بدین ترتیب انطباق ساده حتی با برنامه‌های کاربردی جداگانه امکانپذیر می‌گردد تا منطبق با تغییر Policy و پاسخ‌دهی با شرایط در حال تغییر کسب‌وکار باشد.

Virtual Volume چیست

مقایسه کنترل دقیق‌تر سطح سرویس بین ذخیره‌سازهای قدیمی و Virtual Volume

با استفاده از Virtual Volumes ، امکان آماده‌سازی سریع و پویای سرویس‌های ذخیره‌سازی برای ماشین‌های مجازی جداگانه، با یک رویکرد Policy محور فراهم می‌گردد که منجر به ارائه سطوح بالای خودکارسازی و کنترل ساده‌تر می‌شود.

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

‌LUN‌ها و Volumeها در Storage به صورت Container‌های از پیش تعیین شده می‌باشند در حالی که با Virtual Volumes می‌توان در هنگام نیاز ظرفیت ذخیره‌سازی و سطح سرویس را به شکلی پویا به صورت Real-Time ارائه نمود.

در قسمت بعد از این مقاله به بررسی مزایای استفاده از این تکنولوژی در مجازی‌سازی می‌پردازیم.

ــــــــــــــــــــــــــــــــــــــــــــــ

بررسی VMware vSphere Virtual Volumes یا VVOLs – قسمت اول

بررسی VMware vSphere Virtual Volumes یا VVOLs قسمت دوم (پایانی)

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

ادامه مطلب

معرفی VMware vCenter Server High Availability – قسمت دوم

معرفی VMware vCenter Server High Availability – قسمت دوم

VMware vCenter Server High Availability - VCHA

اقدامات زیادی در خصوص فراهم نمودن قابلیت دسترس‌پذیری بالا (HA) در VMware vCenter Server 6.5 صورت گرفته است تا میزان تاثیر این سرویس و عملیات‌ آن بر عملکرد Server vCenter و Hostهای vSphere را به حداقل میزان ممکن برساند. در قسمت اول از سری مقالات VCHAA به بررسی مفهوم این تکنولوژی پرداختیم. در این مقاله که قسمت دوم (پایانی) می‌باشد، به بررسی ویژگی‌های و برخی تنظیمات آن می‌پردازیم.

عملکرد Failover و (Recovery Time Objective (RTO در VCHA

در صورت بروز خرابی، قابلیت Failover در VCHA به نحوی ارائه می‌گردد که کاربران می‌توانند از طریق API در کمتر از دو دقیقه و از طریق واسط کاربری خود در کمتر از چهار دقیقه به ادامه کار بپردازند. با‌وجود اینکه انجام فرآیند Failover به پیکر‌بندی vCenter Server و اندازه Inventory بستگی دارد اما بر اساس بررسی‌های انجام گرفته محدوده زمانی آن معمولا در حدود ۵ دقیقه می‌باشد.

حداقل زمان فعال‌سازی VCHA

طبق مشاهدات صورت گرفته فعال‌سازی VCHA بسته به نوع پیکر‌بندی vCenter Server و اندازه Inventory حدود چهار تا نه دقیقه به طول می‌انجامد.

سربار حاصل از VMware vCenter Server High Availability

با فعال‌سازی VCHA، تاثیر قابل‌توجهی بر عملکرد vCenter در شرایطی که بارکاری معمولی وجود داشته باشد، احساس نخواهد شد؛ اما در مواقعی که بارکاری زیادی بر روی vCenter ایجاد گردد،کمی در عملکرد vCenter تاثیر‌گذار خواهد بود؛ با این وجود بعید است که کاربران چنین حجم زیادی از بارکاری را در دوره‌های طولانی مدت بر روی Server vCenter ایجاد نمایند.

نمایش تأثیر عملکرد vCenter Server بصورت آماری

با توجه به بررسی‌های انجام شده، با افزایش مقیاس Statistics یا آماری، Server vCenter توان عملیاتی کمتری را ارائه می‌نماید. با فعال‌سازی VCHA در سطوح مختلف Statistics، یک تأثیر قابل ملاحظه اما جزئی، بر توان عملیاتی به میزان ۳ تا ۹ درصد ایجاد می‌شود.

تأثیر اجرای VCHA در یک شبکه‌ خصوصی

طراحی VCHA به نحوی است که از شبکه‌های LAN که نهایتا ۱۰ میلی‌ثانیه تاخیر بین Node‌های VCHA دارند را پشتیبانی می‌نماید، اگرچه این روند نیز با ایراداتی همراه می‌باشد.

مقایسه‌ی PSCهای خارجی با PSCهای Embedشده

عملکرد VCHA با مقایسه‌ی این دوحالت پیاده‌سازی مورد بررسی قرار گرفته و تفاوت اندکی بین آنها مشاهده شده است. یافته‌های حاصل‌ نشان می‌دهد که قابلیت HA درvCenter Server  قادر است در شرایط مختلف به خوبی فعالیت ‌‌نماید.

فعال‌سازی VCHA

امکان فعال‌سازی VCHA در هنگام اجرای Server vCenter فراهم شده است. بر اساس بهترین راهکارهای ارائه شده، جهت دستیابی به بهترین عملکرد، توصیه می‌گردد برای فعال‌سازی VCHA، یک دوره زمانی با بارکاری (Workload) بسیار کم در نظر گرفته شود؛در‌غیر‌اینصورت، دیتابیس Posture SQL جدید که نقش Passive Node را بر عهده خواهد گرفت، ممکن است به دلیل پاک شدن Log‌های تراکنشی درNode Activee امکان هماهنگی کامل و عملکرد مطلوب را نداشته باشد. در حال حاضر اقداماتی در زمینه افزودن پشتیبانی از قابلیت Archive-Log جهت رفع این مشکل صورت گرفته است.

نحوه پیکر‌بندی VCHA

طراحی VMware vCenter HA به نحوی است که در صورت بروز خرابی در یک نقطه واحد می‌تواند با استفاده از قابلیت HA به عملکرد مطلوب خود ادامه دهد. تمامی داده‌های مربوط به وضعیت Nodeهای Active و Passive همسان‌سازی (Replicate) شده و در‌صورت بروز حادثه‌ای‌ برای Active Node‌، Node Passive وارد عمل شده و روند اجرای کار را ادامه می‌دهد. به همین دلیل است نحوه پیکر‌بندی VCHA از اهمیت بالایی برخوردار می‌باشد، زیرا خرابی در یک نقطه بر عملکرد مناسب Node‌های Active ،Passivee و Witness تاثیری نمی‌گذارد.

نکات مهم در پیکربندی VMware vCenter HA

نکاتی که در پیکربندی VCHA باید رعایت شود به شرح زیر می‌باشد:

  • هر VCHA باید به نحوی پیکربندی ‌شود که در صورت بروز اختلال در یک Node تحت تأثیر قرار نگیرد.
  • پیاده‌سازی هر Node بر روی سرورهای مختلف به ‌عنوان یک اقدام احتیاطی در مقابل خرابی‌های سخت‌افزاری از قبیل خرابی CPU، حافظه، کابل یا مادربورد محسوب می‌شود.
  • پیاده‌سازی هر Node در Datastore‌های مجزا به‌عنوان یک اقدام احتیاطی در مقابل خرابی‌ دیسک می‌باشد.
  • سخت‌افزار‌های اضافی مانند منبع تغذیه و خنک‌کننده در زیرساخت فیزیکی، موجب افزایش دسترس‌پذیری می‌گردند. چنانچه اختلال در جریان برق صرفا عملکرد Active Node را مختل سازد، تا زمان فعال بودن سایر Node‌ها، VCHA می‌تواند فرآیند Failover را آغاز نموده و Node Passive را به Active ارتقا می‌دهد.

از سوی دیگر، پیکر‌بندی‌های VM از قبیل تنظیمات منابع در CPU، Memory و Disk باید در بین Node‌ها یکسان باشد. بدین ترتیب تضمین می‌شود که در صورت تبدیل Passive Node به Active ، عملکرد مشابهی خواهد داشت.

پیکر‌بندی شبکه در پیاده سازی VCHA

تکنولوژی VCHA برای پیاده‌سازی در شبکه‌های خصوصی که دارای تاخیر‌ جزئی و پهنای باند بالا می‌باشند، طراحی شده است؛ در مجموع ویژگی‌های متعددی وجود دارد که بر عملکرد کلی VCHA تاثیر‌ می‌گذارد.

  • VCHA ، داده‌های موجود در Nodeهای Passive و Active را Replicate می‌نماید. PostgreSQL به صورت پیش‌فرض و هم‌زمان به انجام این کار پرداخته و در‌صورت مواجهه با هر‌گونه انحراف در حالت ناهماهنگ (Asynchronous) قرار می‌گیرد. به ‌همین‌ دلیل در اختیار داشتن یک شبکه‌ی خصوصی مجزا و مختص به VCH با توانایی ارائه‌ی منابع شبکه فاقد اختلال و مداخله برنامه‌های کاربردی دیگر از اهمیت بالایی برخوردار می‌باشد.
  • VCHA به طور رسمی از شبکه‌های دارای ‌تاخیر کم (تا مرز ۱۰ هزارم ثانیه) پشتیبانی می‌نماید. در صورت تخطی از محدوده‌های پشتیبانی شده نیز VCHA همچنان به ارائه قابلیت HAA ادامه می‌دهد اما با بروز یک خطا در عملکرد ساختار، کابران شاهد تأخیر بسیار زیاد در عملیات و کاهش توان عملیاتی خواهند بود.
  • در اختیار داشتن یک شبکه با پهنای باند بالا برای فعال‌سازی ویژگی‌های VCHA از نکات مهم محسوب می‌گردد که توانایی انجام دو عملیات Clonee را داشته و نیاز شبکه را برطرف نماید.

دلایل استفاده از HA در VMware vCenter Server

با توجه به موارد عنوان شده در این مقاله، وجود سرویس‌های HA در هر پلتفرمی حائز اهمیت می‌باشد وvCenter Server هم از این قضیه مستثنی نیست. این تکنولوژی به‌عنوان ابزار اصلی اجرا و مدیریت vSphere فاکتور مهمی در شبکه محسوب می‌گردد که پیاده‌سازی HA برای آن اهمیت می‌یابد. VCHA، محافظت در برابر مشکلات نرم‌افزاری و سخت‌افزاری را به همراه عملکردی مطلوب در سناریوهای معمول کاربران ارائه می‌نماید.

با توجه به بررسی های انجام شده در عملکرد تکنولوژی VCHA و با شبیه‌سازی فعالیت‌های معمولِvCenter Server  در سناریوهای رایج و تست آن در بدترین شرایط ممکن، نتایجی بدست آمده است که پیرو آن، داده‌های قطعی و شاخص‌های جامع عملکردی در زیر عنوان شده است:

  • عملکردFailover یا RTO در VCHA
  • عملکرد فعال‌سازی VCHA
  • Overhead VCHA
  • تأثیر عملکرد مقیاس آماری در vCenter Server
  • تأثیر اجرای این تکنولوژی در شبکه‌های خصوصی
  • مقایسه External PSC و Embedded PSC

ــــــــــــــــــــــــــــــــــــــــــ

معرفی VMware vCenter Server High Availability – قسمت اول

معرفی VMware vCenter Server High Availability – قسمت دوم (پایانی)

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

ادامه مطلب

معرفی VMware vCenter Server High Availability – قسمت اول

معرفی VMware vCenter Server High Availability – قسمت اول

VMware vCenter Server High Availability - VCHA

پلتفرم VMware vSphere یکی از پلتفرم‌های مجازی‌سازی است که مبنایی برای ایجاد و مدیریت زیرساخت‌های مجازی برای Private Cloud و Public Cloud در سازمان‌ها به شمار می‌رود. VMware vCenter Server Appliance یا به اختصار vCSA، در هسته اصلی vSphere قرار گرفته و سرویس‌هایی را برای مدیریت بخش‌های مختلف در زیرساخت‌های مجازی مانند HostهایESXi ، ماشین‌های مجازی، منابع شبکه و ذخیره‌سازی ارائه می‌نماید. از آنجایی که زیرساخت‌های مجازی بزرگ با استفاده از vSpheree ایجاد می‌شوند، vCenter Serverr به عنوان یکی از عوامل مهم در تضمین تداوم کسب‌وکار در یک سازمان محسوب می‌گردد.

vCenter Server باید خود را در مقابل مجموعه‌ای از خرابی‌های سخت‌افزاری و نرم‌افزاری در محیط محافظت نموده و پس از بروز این خرابی‌ها نیز به صورت Transparent بازیابی شود. vSphere 6.5 یک راهکار با دسترس‌پذیری بالا (HA) برای vCenter Server ارائه می‌نماید که تحت عنوان VMware vCenter Server High Availability یا به اختصار VCHAA شناخته می‌شود.

بررسی معماری VMware vCenter Server High Availability

درمعماری vCenter High Availability از یک کلاستر دارای سهNode  استفاده می‌شود تا قابلیت HA در برابر انواع مختلفی از مشکلات سخت‌افزاری و نرم‌افزاری را ایجاد نماید. کلاستر vCenetr HA دارای یک Active Node جهت پاسخگویی به درخواست‌های Client، یک Passive Node برای ارائه سرویس به جای Active Node در صورت بروز خرابی و یک Quorum Node تحت عنوانWitness  می‌باشد. تمامی معماری‌های مبتنی بر Node که در قالب Active یا Passive از فرآیند Failoverr به صورت اتوماتیک پشتیبانی می‌نماید، با اتکا بر موجودیت Tie Breaking یا Quorum به حل مشکل Split-Brain می‌پردازد؛ لازم به ذکر است مشکل Split-Brainn به عدم هماهنگی و انطباق داده‌ها و قابلیت دسترس‌پذیری اطلاق می‌شود که می‌تواند به دلیل خرابی شبکه در سیستم‌های توزیعی که داده‌های Replicate شده را نگهداری می‌کنند، بروز نماید. در معماری‌های قدیمی از انواع مختلف Shared Storage‌ برای حل مشکل Split-Brain استفاده می‌شود اما در این طرح که با هدف پشتیبانی از یک کلاستر vCenter HA در چندین دیتاسنتر می‌باشد، پیاده‌سازی مبتنی بر Shared Storage مورد نظر قرار نمی‌گیرد.

در نتیجه‌ی این طراحی همواره یک Node در کلاستر vCenter HA به عنوان Quorum Node یا Witness Node تعیین می‌گردد؛ همچنین دو Node دیگر با نقش‌های Active و Passive در نظر گرفته می‌شوند.

دسترس‌پذیری یک vCenter Server تا زمانی تضمین می‌شود که دو Node فعال در داخل یک کلاستر وجود داشته باشد، اما در صورتی که فقط دو Node در کلاستر وجود داشته باشد، وضعیت کلاستر در حالت Degradedd در نظر گرفته می‌شود و بروز خرابی بعدی در این کلاستر به معنای در دسترس نبودن سرویس‌های vCenter خواهد بود.

vCenter Server Appliance به صورت Stateful بوده و برای عملکرد درست به یک حالت پایدار نیاز دارد. وضعیت Appliance (وضعیت پیکربندی یا زمان اجرا) عمدتا شامل موارد زیر می‌باشد:

  • ذخیره سازی داده‌های پایگاه داده در دیتابیسی تحت عنوان PostgreSQL
  • فایل‌های Flat مانند فایل‌های پیکربندی

پشتیبان‌گیری از وضعیت Appliance به دلیل تاثیر‌گذاری در عملکرد صحیح VCHA Failover موضوعی مهم قلمداد می‌گردد. در شرایطی که ذخیره‌سازی وضعیت در داخل پایگاه‌داده PostgreSQL انجام شود، از مکانیسم Replication که به صورت Native در PostgreSQL وجود دارد جهت همسان‌سازی داده‌ها در پایگاه‌داده اولیه و ثانویه استفاده می‌شود. به منظور همسان‌سازی فایل‌های Flat نیز از یک راهکار Native لینوکسی با نام Rsync استفاده می‌گردد.

از آنجایی که vCenter Server Appliance نیاز به هماهنگی و سازگاری زیادی دارد، استفاده از روش‌های Replication هماهنگ، جهت Replicate نمودن وضعیت Appliance از Active Node به Passive Node جزو ملزومات اساسی می‌باشد.

طراحی مناسب شبکه در این تکنولوژی باید ارتباطات مناسب (تاخیر کم و پهنای باند بالا) بین Nodeهای Active و Passive که تضمین‌کننده‌ی Recovery Point Objective یا به اختصار RPO با مقدار صفر می‌باشد را ارائه نماید.

کلاستر vCenter HA به شبکه مخصوص خود نیاز دارد که از شبکه مدیریتی برای vCenter Server Appliance جدا می‌باشد. همچنین باید سه FQDN یا IP‌ استاتیک به هر یک از Nodeها اختصاص داده شود که برای ترافیک کلاستر VCHA در شبکه‌ اختصاصی آن، مورد استفاده قرار می‌گیرند. Clientها می‌توانند از طریق واسط کاربری مدیریتی شبکه که به صورت عمومی می‌باشد به سرور Active دسترسی یابند.

در ادامه به بررسی نقش‌های هر یک از Nodeها در کلاستر vCenter HA می‌پردازیم:

بررسی Active Node:

  • Node اجرا کننده‌ی Active Instance مربوط به vCenter Server
  • دارای قابلیت ایجاد و استفاده از Public IP مربوط به کلاستر

بررسی Passive Node:

  • Node اجرا کننده‌ی Passive Instance مربوط به vCenter Server
  • دارای قابلیت دریافت به روزرسانی‌های پیوسته مربوط به وضعیت Active Node در شرایط همزمان
  • همانند Active Node در رابطه با منابع
  • دارای قابلیت اجرای نقش Active Role در صورت بروز Failover

بررسی Witness Node:

  • دارای قابلیت عملکرد به عنوان Quorum Node
  • مورد استفاده برای قطع ارتباط در صورت بخش‌بندی شبکه و ایجاد موقعیتی که Nodeهای Active و Passive قادر به برقراری ارتباط با یکدیگر نباشند.
  • یک ماشین مجازی با استفاده از حداقل منابع سخت‌افزاری و تصرف یک فضای محدود
  • عدم پذیرش نقش Nodeهای Active و Passive

در صورت بروز مشکل برای Active Node به هر دلیلی مانند مشکلات سخت‌افزاری، نرم‌افزاری یا شبکه‌ای، Passive Node نقش آن را به عهده گرفته و با استفاده از Public IP در نظر گرفته برای کلاستر فرآیند پاسخگویی به درخواست‌های Client را آغاز می‌نماید.

در عین حال انتظار می‌رود که Clientها برای ادامه دسترسی به Appliance نیاز به Log On نمودن مجدد داشته باشند. از آنجایی که راهکارهای HA از فرآیند Replication همزمان پایگاه‌داده استفاده می‌نمایند، در طول Failover هیچ اطلاعاتی از بین نخواهد رفت که این موضوع به معنای صفر بودن RPO می‌باشد.

قابلیت دسترس‌پذیری vCenter Server Appliance در صورت بروز خرابی در هر یک از Node‌ها مطابق با شرایط زیر عمل می‌نماید:

  1. خرابی Active Node

تا زمانی که ارتباط بین Passive Node و Witness Node برقرار باشد، Passive Node می‌تواند وضعیت خود را به حالت Active ارتقا داده و  درخواست‌های Client را پاسخ دهد.

۲. خرابی Passive Node:

تا زمانی که ارتباط بین Active Node و Witness Node برقرار باشد، Active Node می‌تواند به صورت فعال به اجرای نقش خود پرداخته و درخواست‌های Client را پاسخ ‌دهد.

۳. خرابی Witness Node:

تا زمانی که ارتباط بین Active Node و Passive Node برقرار باشد، Active Node همچنان فعالانه به اجرای نقش خود پرداخته و درخواست‌های Client را پاسخ می‌دهد. ضمن اینکه Passive Node نیز به مراقبت از Active Node برای بروز Failover ادامه می‌دهد.

۴. خرابی بیش از یک Node یا جدا شدن Nodeها

این شرایط زمانی رخ می‌دهد که هر سه Node مربوطه یعنی Active, Passive و Witness قادر به برقراری ارتباط با یکدیگر نباشند. این حالت مربوط به زمانی است که خرابی در بیش از یک نقطه روی می‌دهد و در این صورت کلاستر غیرکاربردی فرض شده و قابلیت دسترس‌پذیری آن نیز تحت تاثیر قرار می‌گیرد زیرا VCHA برای پاسخگویی در شرایط بروز مشکل برای بیش از یک Node طراحی نشده است.

۵. رفتار مجزای Nodeها

  • در صورت جدا شدن یک Node از کلاستر، این Node به صورت خودکار از کلاستر خارج شده و تمام سرویس‌ها متوقف می‌شوند. به عنوان مثال، در صورت جدا شدن Active Node، تمامی سرویس‌ها به منظور تضمین این موضوع که آیا Passive Node در صورت حفظ ارتباط باWitness Node قادر به پذیرش مسئولیت می‌باشد یا خیر، متوقف می‌شوند.
  • ناکارآمدی‌های متناوب شبکه در فرآیند شناسایی Node جدا شده، مورد توجه قرار گرفته و پس از به نتیجه نرسیدن تمامی تلاش‌ها در یک حالت مجزا قرار می‌گیرد.

تعامل Client و Failover

Client‌ها برای ارتباط با vCenter Server Appliance از IP Public استفاده می‌نماید. در صورتی که Failover رخ دهد، Passive Node مسئولیت Active Node‌ دچار مشکل شده را که دارنده‌ی Public IP نیز بوده بر عهده خواهد گرفت.

میزان Recovery Time Objective یا RTO در این راهکار چند دقیقه می‌باشد که در طول این مدت Client باید برای اختلال‌های پیش آمده آمادگی داشته باشد.

در قسمت دوم (پایانی) از سری مقاله‌های HA در VMware vCenter به بررسی ویژگی‌های این تکنولوژی و برخی تنظیمات آن خواهیم پرداخت.

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

ادامه مطلب

بررسی قابلیت‌های NetScaler همراه با Unified Gateway

بررسی قابلیت‌های NetScaler همراه با Unified Gateway

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

با استفاده از تکنولوژی Citrix NetScaler همراه با Unified Gateway، امکان دسترسی ایمن و Remote کاربران به برنامه‌های پیاده‌سازی شده مورد نیاز کسب‌وکار در دیتاسنتر یا Cloud در طیف وسیعی از تجهیزات شامل لپ‌تاپ، دسکتاپ، Thin Client، تبلت و تلفن‌های هوشمند فراهم می‌گردد. این تکنولوژی به ارائه یک زیرساخت یکپارچه می‌پردازد که موجب ساده‌سازی ساختار IT و کاهش هزینه‌های کلی مالکیت (TCO) در رابطه با زیرساخت دیتاسنتر می‌گردد.

یکپارچهسازی زیرساخت دسترسی Remote با One URL

Citrix NetScaler در کنار Unified Gateway با ارائه One URL به یکپارچه‌سازی زیرساخت دسترسی Remote می‌پردازد. ضمن اینکه دسترسی Remote به محیط CitrixApp و XenDesktop، دسترسی Remote و مبتنی بر SSL VPN به برنامه‌های سازمانی مانند RDR Web و برنامه‌های کاربردی Cloud و همچنین یکپارچه‌سازی با XenMobile به عنوان یک راهکار MDM/MAM را فراهم می‌نماید.

NetScaler - Unified Gateway

این امر موجب بهبود کارایی و کاهش هزینه مالکیت در IT می‌شود. این تکنولوژی به ارائه One URL برای کاربران نهایی می‌پردازد تا دسترسی آنها به برنامه‌های کاربردی را از موقعیت‌های مکانی Remote فراهم نموده و تجربه مطلوبی را برای کاربران ایجاد کند.

کاربران می‌توانند با دسترسی به One URL با استفاده از هر نوع تجهیزاتی به تمامی برنامه‌های کاربردی دسترسی داشته باشند.

پورتال سفارشی 

NetScaler با Unified Gateway به ارائه یک پورتال کاملا سفارشی می‌پردازد که امکان تبدیل هر یک از استاندارهای سازمانی به برند مورد نظر را برای کاربران فراهم می‌نماید. بدین ترتیب آنها می‌توانند لوگو، رنگ پس زمینه، توافقات EULA و سایر موارد را به عنوان بخشی از این فرآیند سفارشی‌سازی انتخاب نمایند.

ارائه قابلیت دید برای ترافیک‌های XenApp و XenDesktop با HDX Insight

HDX Insight می‌تواند روند کنترل هزینه‌ها و غلبه بر موانع دستیابی به قابلیت دید بهتر نسبت به برنامه‌ها را در سازمان‌های IT تسهیل نماید. این موانع و هزینه‌ها می‌تواند شامل نیاز به پیاده‌سازی Intrusive Network Tap، نصب Agentهای نرم‌افزارها بر روی هر سرور و یا تجهیز هر برنامه برای مانیتورینگ تخصصی باشد. با این تکنولوژی می‌توان امکان اجرای هر دو نوع مانیتورینگ Real-Timee و مبتنی بر زمان را برای مدیران و تیم‌های پشتیبانی ITT فراهم نمود.

NetScaler - Unified Gateway

یکپارچهسازی با XenDesktop و NetScaler Insight

راهکار HDX Insight به منظور ارائه یک کنسول واحد برای مدیریت و مانیتور نمودن برنامه‌های کاربردی XenApp و XenDesktop با ابزارهای مدیریتی XenApp و XenDesktopp یکپارچه می‌گردد.

HDX/ICA Proxy به عنوان یک کلاستر

با استفاده از این ویژگی، مدیران می‌توانند NetScaler همراه با Unified Gateway را جهت فراهم کردن دسترسی XenApp و XenDesktop در کلاستری که تمامی Nodeها در آن به ترافیک پاسخ می‌دهند، پیاده‌سازی نمایند. به علاوه مدیران می‌توانند از پیکربندی فعلی Gateway نیز استفاده نموده و بدون نیاز به محدود نمودن پیکربندی VPN به یک Node واحد، آن را به صورت یکپارچه در پیاده‌سازیِ کلاستر توسعه دهند.

با ویژگی HDX Insight، امکان پیکربندی و پیاده‌سازی این تکنولوژی در یک فضای کلاستری و مشاهده گزارش‌های جمع‌آوری شده در NetScaler Insight Center در سراسر کلاستر برای مدیران فراهم می‌گردد.

مدیریت ساده و متمرکز

SmartControl، امکان مدیریت Policyهای مربوط به برنامه‌های کاربردی XenApp و XenDesktop را از یک موقعیت متمرکز فراهم می‌نماید. این تکنولوژی در روند مدیریت Policyهای XenApp و XenDesktop از قبیل پرینت، کپی و Paste در تجهیزات Gateway به مدیران کمک می‌کند. علاوه بر این، اجرای Policyها را نیز تضمین نموده و امنیت و قابلیت مدیریت‌پذیری را بهبود می‌بخشد.

دسترسی یکپارچه

NetScaler با Unified Gateway به ارائه قابلیت Federated Identity بر اساس استانداردهای SAML 2.0 برای ارائه (SSO (Single Sign-On در میان برنامه‌های کاربردی می‌پردازد. کاربران می‌توانند بین XA/XD و برنامه‌های کاربردی تحت وب، سازمانی و یا موجود بر روی Cloud جابجا شوند بدون آنکه نیازی به log-In مجدد داشته باشند.

قابلیت Content Switching

مدیران با کمک این تکنولوژی می‌توانند صرفا به پیکربندی یک Public IP برای پاسخ به درخواست‌های هر یک از برنامه‌ها بپردازند که این درخواست‌ها ممکن است از طریق Citrix Receiver و Tunnel SSL VPN برای برنامه‌های قدیمی یا سیار و یا XenMobile Appهایی مانند Worx Home باشد. فرآیند Content Switching می‌تواند قابلیت SSOO یکپارچه در برنامه‌های کاربردی را امکانپذیر نماید.

ارائه RDP Proxy به صورت Stateless

این تکنولوژی به مدیران این امکان را می‌دهد تا آن را به عنوان یک Proxy برای سرورهای RDP/Terminal پیکربندی نموده و دسترسی یکپارچه به کاربر نهایی را ارائه نمایند.

پشتیبانی از اندروید و iOS

این تکنولوژی به ارائه SSL VPN Client برای پلتفرم‌های اندروید و iOS نیز می‌پردازد. بنابراین مدیران می‌توانند برای دسترسی ایمن و Remote به هر یک از برنامه‌ها و تجهیزات، یک VPN Tunnel تنظیم نمایند.

پشتیبانی از لینوکس، ویندوز و MAC

این تکنولوژی علاوه بر پشتیبانی از سیستم عامل‌های MAC و ویندوز، در حال حاضر از پلتفرم‌های لینوکس نیز پشتیبانی می‌نماید.

آنالیز Endpoint

با قابلیت اسکن یکپارچه Endpoint تضمین می‌شود که تجهیزات متصل به شبکه علاوه بر سازگاری با Policyهای سازمانی، از ایمنی لازم هم برخوردار می‌باشند. در صورتی که کاربران موفق به logon نشوند، می‌توانند مراحل به‌روزرسانی تجهیزات را طی نموده و به سازگاری لازم دست یابند. این تکنولوژی با استفاده از قابلیت گروه‌های سالم‌سازی (Remediation) و امکان اجرای اصلاحات مورد نیاز مانند دریافت به روزرسانی‌های لازم برای Client‌های که دسترسی آن‌ها محدود شده است، تطبیق‌پذیری با Policyهای سازمان را میسر سازد.

پشتیبانی IPv6

NetScaler به پشتیبانی از IPv6 برای پلتفرم‌های معمول موجود در صنعت می‌پردازد.

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

ادامه مطلب

بررسی معماری VMware vSphere Virtual Volumes یا VVOLs

بررسی معماری VMware vSphere Virtual Volumes یا VVOLs

با توجه به مطالب عنوان شده در سری مقالات “بررسی VMware vSphere Virtual Volumes یا VVOLs” به بررسی مفهوم این تکنولوژی پرداختیم و در این مقاله نیز به بررسی نحوه عملکرد و معماری این تکنولوژی خواهیم پرداخت.

Virtual Volume یک معماریِ بسیار متفاوت و بهبود یافته نسبت به ذخیره‌سازی منطقی (Storage Logical) ارائه می‌کند که امکان اجرای عملیات‌ را در سطح ماشین مجازی فراهم نموده و همچنین از قابلیت‌های Array به صورت Native بهره می‌برد؛ با استفاده ازVirtual Volume نیاز به آماده‌سازی و مدیریت تعداد زیادی LUN یا Volumee جهت دستیابی به سرویس‌‌ها در سطح برنامه‌های کاربردی بر روی Host از بین می‌رود، بدین ترتیب قابلیت مدیریت زیرساخت vSpheree از طریق کاهش سربار عملیاتی افزایش یافته و در عین حال سرویس‌های داده‌ی مقیاس‌پذیر در هر یک از سطوح ماشین مجازی فعال می‌گردد.

VMware vSphere Virtual Volumes یا VVOLs

معماری Logical برای Virtual Volumes

Virtual Volume‌ به پشتیبانی VMware و ‌Vendor‌های ارائه دهنده‌ی Storage نیاز دارند. از دیدگاه VMware، عوامل کلیدی در ارائه Storageهای مبتنی بر نرم‌افزار شامل vSphere Virtual Volumes، vSphere Storage-Policy Based Management و (VASA (vSphere APIs for Storage Awareness  می‌باشند.

از دیدگاه Vendor‌های ارائه دهنده Storage نیز Array باید برای Virtual Volumes فعال شود و Vendor‌ها باید یک vSphere API را برای ارائه‌دهنده‌ی (VASA (Storage Awarenessعرضه نمایند که با نسخه ۲ از APIهای VASA هماهنگ بوده و به منظور برقراری ارتباطات خارج از محدوده به‌ کار می‌رود.

هنگامی که Admin Storage به تعریف قابلیت‌های قابل استفاده‌ Storage Array می‌پردازد، این قابلیت‌ها با استفاده از APIهای VASA، در vSphere نشان داده شده و برای استفاده در دسترس مدیران vSphere قرار می‌گیرند. سپس Policy‌های مربوط به Storage از مجموعه‌ قابلیت‌های ارائه شده ‌برای Storage Array توسط مدیران vSphere ایجاد می‌شوند.

همچنین یک ساختار جدیدِ مسیر داده‌ به نام Protocol Endpoint یا به اختصار PE، به منظور ایجاد مسیر مستقیم انتقال داده از Host به Storage اصلی ارائه شده است. به این ترتیب یک مسیر جدید برای ارتباطات API و Policyy ایجاد می‌شود که برای هر یک از آنها مجزا بوده و به Vendorrهای شخصی این امکان را می‌دهد تا قابلیت خودترمیمی مسیر داده را بسته به قابلیت‌های خاص، سفارشی‌سازی نماید.

علاوه بر موارد ذکر شده، یک مجموعه‌ جدید از مکانیسم‌های ارتباطی و ساختارهای مدیریتی به منظور مدیریت، مانیتور و فعال‌سازی ویژگی‌ها و قابلیت‌های جدید ارائه شده توسط Virtual Volumes، عرضه گردیده است.

Protocol Endpoint یا به اختصار PE

Protocol Endpoint یک مکانیسم انتقال یا مجموعه‌ای از Access Point‌ها محسوب می‌شود که کنترل دسترسی و ارتباطات را بین Hostهای ESXi و سیستم‌های Storage Arrayy فعال نموده و مدیریت می‌کند.

PE به عنوان بخشی از پیکره‌ی فیزیکی Storage محسوب شده و این قابلیت را دارد که مسیرهای داده را در صورت نیاز از ماشین‌های مجازی به Virtual Volumes مربوطه ایجاد نماید. لازم به ذکر است که PE عملکردهای دسترسی مربوط به LUNهای امروزی را در خود دارد، بنابراین از تمام پروتکل‌های استاندارد صنعتی پشتیبانی می‌نماید؛ در نتیجه‌، کاربر نهایی می‌تواند از Virtual Volumes بدون ایجاد خدشه در پیکربندی فعلی خود بهره گیرد. هدف Protocol Endpoint علاوه بر پشتیبانی از پروتکل‌های فعلی، کمک به روند توسعه می‌باشد که بر خلاف LUNها که از سقف تعریف ‌شده‌‌ای برای اتصال برخوردار است، امکان اتصال یک PE واحد به چندین Virtual Volume فراهم می‌باشد.

علاوه بر موارد ذکر شده، Protocol Endpoint با تمام پروتکل‌های استاندارد صنعتی SAN و NAS سازگاری دارد. این پروتکل‌ها عبارتند از:

در ضمن، تنظیم و پیکربندی Protocol Endpoint توسط مدیران Storage انجام می‌پذیرد.

مفهوم Storage Container یا به اختصار SC

Virtual Volume‌ها بر روی Containerهای Storage ایجاد می‌شوند؛ این Containerها در واقع ساختاری از Storageهای منطقی می‌باشند که توسط مدیران Storage تنظیم و تعریف شده و برای تعریف موارد زیر استفاده می‌شوند:

  • اختصاص ظرفیت Storage و محدودیت‌های آن
  • تنظیمات Policy برایStorage بر مبنای قابلیت‌های سرویس داده و بر اساس هر یک از ماشین‌های مجازی
VMware vSphere Virtual Volumes یا VVOLs

Storage Container و Virtual Volumes

Storage Container یک ساختار کاملا منطقی در Array می‌باشد که میزان فضای تعریف شده توسط کاربر را برای مجموعه‌ای از قابلیت‌ها و ظرفیت Storage در نظر می‌گیرد و به عنوان یک Datastore مجازی برای vSphere ارائه خواهد شد.

بنابراین Admin Storage می‌تواند ظرفیت و قابلیت‌ها را در قالب گروه‌بندی‌های منطقی پیکربندی نماید. علاوه بر این، امکان تعامل Admin vSphere با Datastoreهای شناخته شده فراهم می‌گردد بدون آنکه نیازی به کسب دیدگاه نسبت به ساختارهای فیزیکی مربوط بهStorage Container باشد.

در این معماری، Storage Container در دسترسِ Host ESXi قرارگرفته و دارای رابطه‌ یک به یک با Storage Container‌های ایجاد شده بر روی Storage Array می‌باشد. برای مثال در صورتی که کاربر سه Storage Container بر روی Array ایجاد نماید، به همین تعداد Datastore VVol مرتبط در اختیار خواهد داشت که برای استفاده در Hosttهای متصل، در دسترسِ می‌باشد.

تنظیم و پیکربندی Storage Container‌ها نیز همچون PE توسط Storage Admin صورت می‌گیرد و سپس در هنگام افزودن Datastoreهای مجازی به‌طور خودکار در vSphere شناسایی می‌شوند.

VMware vSphere Virtual Volumes یا VVOLs

افزودن Datastore از نوع Virtual Volume در vSphere

بررسی Vendor Provider یا به اختصار VP

Vendor Provider که با نام VASA Provider نیز در نظر گرفته می‌شود، یک Component نرم‌افزاری برای Storage محسوب می‌گردد که به عنوان یک سرویس Storage Awareness برای vSphere عمل می‌کند. Vendorهای ارائه دهنده‌ی Storage به طور انحصاری به توسعهVP می‌پردازند.

Hostهای ESXi و vCenter Server به VP متصل شده و اطلاعاتی درباره‌ی توپولوژی، قابلیت‌ها و وضعیتِ Storageهای فعلی ارائه می‌نمایند. سپس vCenter Server این اطلاعات را در اختیار Clientهای vSphere قرار داده و به این ترتیب قابلیت‌هایی را به نمایش می‌گذارد که مدیران می‌توانند Policyهای ذخیره سازی در SPBM را بر طبق آنها شکل ‌دهد.

Vendor Provider می‌تواند به شکل یک Appliance مجازی و یا مستقیما از جایگاه مدیریتِ Array به اجرا درآید. با استفاده از این روش، VP با قابلیت‌های Array از طریق Storage API‌های vSphere مرتبط می‌گردد تا ویژگی‌ها و قابلیت‌های Storage Array را در برگیرد و آنها را از طریق API‌های  VASA با هدف کاربرد برای هر یک از ماشین‌های مجازی به صورت Granular به vSphere ارائه دهد.

VP عموما توسط vSphere Admin و به یکی از دو روش زیر تنظیم و پیکربندی می‌گردد:

  • به صورت خودکار از طریق Plug-In Array Vendors
  • به صورت دستی از طریق vCenter Server
VMware vSphere Virtual Volumes یا VVOLs

ثبت‌نام Vendor VASA Provider به صورت دستی

 بررسی Virtual Volume یا به اختصار VVol

Virtual Volume نوع جدیدی از ماشین‌های مجازی محسوب می‌شود که به صورت Native در Storage Array ایجاد و ذخیره می‌گردد. VVol بر روی Storage Containerها ذخیره شده و به فایل‌ها یا Objectهای ماشین مجازی مانند VM Swap، VMDKs و دیگر موارد مرتبط با آن‌ها Map می‌شود.

Objectهای Virtual Volume در ۵ نوع متفاوت وجود دارد که هرکدام در راستای یک فایل خاص و متفاوت ماشین‌ مجازی فعالیت می‌کند.

VMware vSphere Virtual Volumes یا VVOLs

انواع مقولات مربوط به vSphere Virtual Volumes

  • Config-VVolVM Home، فایل‌های مربوط به پیکربندی، Logها و غیره
  • Data-VVolمعادل VMDKs
  • Memory-VVolSnapshotها
  • Swap-VVolVM memory swap
  • Other-VVolنوع کلیِ مختص راهکار (Solution Specific)
VMware vSphere Virtual Volumes یا VVOLs

Storage Admin View مربوط به VVols در Storage Array

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

ادامه مطلب

مجازی سازی (Virtualization) چیست؟ – قسمت دوم

مجازی سازی (Virtualization) چیست؟ – قسمت دوم

 

مجازی سازی (Virtualization) چیست

 

مجازی سازی (Virtualization) چگونه به کسب و کار کمک می نماید ؟

علاوه بر مسئله ی صرفه جویی اقتصادی، مجازی سازی (Virtualization) می تواند چابکی کسب و کار یک شرکت را به طور قابل ملاحظه ارتقا دهد. شرکت هایی که از Clustering، Partitioning، مدیریت حجم کاری (Workload Management) و دیگر تکتیک های مجازی سازی در پیکربندی گروهی از سرور ها برای بهره برداری از منابع استفاده می کنند،  در مواجهه با تغییرات  نیاز های محیطی در استفاده از منابع خود وضعیت بهتری دارند.

تفاوت بین انواع روش های مجازی سازی (Virtualization):

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

  • مجازی سازی مبتنی بر فضای ذخیره سازی: فضاهای ذخیره سازی فیزیکی را با فضاهای ذخیره سازی دستگاه های موجود در شبکه با هم ادغام می کند به طوری که همانند یک دستگاه ذخیره سازی وانمود می کند .
  • مجازی سازی مبتنی بر شبکه: ترکیب منابع در یک شبکه و تقسیم پهنای باند  در دسترس به کانال های مستقل، که توانایی اختصاص داده شدن به سرورها یا دستگاه های خاص در یک زمان را دارا می باشند.
  • مجازی سازی مبتنی بر سرور: در این حالت، طبیعت فیزیکی سرور ها از جمله تعداد و شناسه ی سرور ها، پردازنده ها و سیستم عامل ها از نرم افزار هایی که بر روی آن ها در حال اجرا می باشند، پنهان می شود.

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

لغات پر کاربرد در مجازی سازی:

Hypervisor: اساسی ترین جز در مجازی سازی (Virtualization) می باشد. Hypervisor نرم افزاری است که باعث جداسازی سیستم عامل و برنامه ها از منابع فیزیکی آن ها می گردد. این جز، کرنل خود را دارا بوده و مستقیما روی سخت افزار نصب می گردد و دقیقا بین سخت افزار. سیستم عامل قرار می گیرد.

Virtual Machine: یا VM که یک محیط عملیاتی است و میزبان سیستم عامل می شود. به عبارت دیگر یک پلت فرم است که مستقل از نرم افزار پیاده سازی پردازنده کد های کامپایل شده را اجرا می کند . همچنین گاهی به تکنولوژی های مجازی سازی نرم افزار Virtual Machine پویا (Dynamic Virtual Machine) نیز گفته می شود.

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

   Xen :Xen پروژه ای است که هدف آن ایجاد یک hypervisor تکامل یافته، رایگان و متن باز برای معماری X86 می باشد. Xen در واقع بر روی بستر یک سیستم عامل اجرا می شود و ابزاری برای فناوری مجازی سازی در نظر گرفته می شود. هم اکنون شرکت های بزرگی ازXen  پشتیبانی می نمایند. مانند: Microsoft، Novell و IBM.

در مجازی سازی باید چه چیزی را جستجو نمود؟

در یک کلام، مدیریت. در واقع شرکت های بزرگ فروشنده ی نرم افزار(Microsoft، Sun Microsystems ، BEA Systems،  Hewlett-Packard،  BMC  و  CA) به این مقوله توجه کرده و آن را در محصول خود می گنجانند، اما فروشندگان مستقل نرم افراز های مجازی سازی (Virtualization) از آن دوری می نمایند. در حقیقت تفاوت این دو گروه در توانایی آن ها در ارائه ی ابزار برای مدیریت، مانیتورینگ و بهینه سازی اختصاص منابع می باشد.

در نتیجه، نسل بعدی محصولات حول محور مدیریت می چرخد. شرکت های بزرگی مثل VMware با راهکار مجازی سازی خود که ESX Server می باشد، به دنبال ادغام فضای ذخیره سازی، پردازنده ها، حافظه ی جانبی و برنامه ها به عنوان یک منبع یکپارچه می باشند.

مجازی سازی (Virtualization) چیست

مجازی سازی (Virtualization) راه درازی تا کاهش حداکثری استفاده از منابع سخت افزاری دارد، اما می تواند تا حدی روش های مدیریتی را با هم ترکیب کند. از دیگر راهکار های مورد نظر در این فناوری به وجود آمدن فرآیندی برای انتقال سیستم ها از حالت فیزیکی به ساختار مجازی می باشد به طوری که با کمترین تغییرات انجام گیرد. به این قابلیت  “Live Migration” می گویند که شرکت های پیشرو در این تکنولوژی در حال ارائه ی آن می باشند.

ــــــــــــــــــــــــــــــــــ

مجازی سازی (Virtualization) چیست؟ – قسمت اول

مجازی سازی (Virtualization) چیست؟ – قسمت دوم

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

ادامه مطلب

سبد خرید شما