Real Time Web Analytics

آموزش و يا مشكل مورد نظر خود را از ما بپرسيد.

در صورت وجود مطلب یا راه حل ، برای شما نمایش داده خواهد شد.

معرفی Vsphere Suite 6 (بخش چهارم)

مقاله قبلی pointing-hand-icon-11731432-hand-and-finger-pointing-illustration معرفی Vsphere Suite 6 (بخش سوم)

مقاله بعدی  ۲ نصب VMware ESXi

با سلامی دوباره

تا این مرحله با برخی محصولات VMware vSphere suite آشنا شده ایم و در این قسمت با برخی از قابلیت ها و Feature ها آشنا خواهیم شد .

vSphere Virtual Symmetric Multi-Processing

این قابلیت که با نام vSMP یا Virtual SMP نیز شناخته می شود به ما این امکان را می دهد تا VM هایی با چندین CPU مجازی بتوانیم ایجاد کنیم . با این امکان هر VM می تواند دارای چندین cpu مجازی با Core ها و Socket های مختلف باشد .

Feature1

همانطور که در تصویر نیز مشاهده می کنید VM ها با این تکنولوژی می توانند بیش از ۱ عدد virtual CPU داشته باشند . به واسطه این قابلیت اکثر application هایی که نیاز به تعدادی cpu جهت اجرا شدن دارند ، به راحتی بر روی VM ها می توانند نصب شوند و از بابت برنامه های کاربردی با پراسس بالا کمبودی نخواهیم داشت و این برنامه ها در محیط مجازی سازی شده با بهترین performance می توانند پیاده سازی شوند .

vSphere vMotion

احتمالا خیلی از دوستانی که با دنیای مجازی سازی تا حدی آشنایی دارند ، مفهوم vMotion و مزایای استفاده از آن را شنیده باشند . همانطور که در قسمت های قبل بررسی کردیم ، در محیط مجازی سازی VMware که پیاده سازی می شود ، تعدادی Host خواهیم داشت (ESXi) که در داخل هر هاست نیز تعدادی Virtual Machine (VM) خواهیم داشت .

قابلیت vMotion که آن را تحت عنوان live migration نیز می شناسیم ، به ما این امکان را می دهد تا یک VM از یک هاست فیزیکی به هاست فیزیکی دیگر منتقل شود حتی بدون اینکه آن VM را خاموش و power off کرده باشیم . این عمل انتقال سرور مجازی یا همان VM بین هاست های فیزیکی یا همان ESXi ها بدون هیچ گونه downtime صورت می گیرد و حتی ارتباطات شبکه ای VM نیز دچار اشکال نخواهد شد . به عبارتی دیگر اگر VM در حال سرویس دهی به کاربران شبکه باشد و عمل migration صورت پذیرد ، بدون اینکه سرویس دهی قطع شود و کاربران متوجه این عملیات شوند ، VM از یک هاست به هاست دیگر منتقل می شود .

vmotion1

عمل vMotion که به صورت دستی و manual  برای VM ها صورت می پذیرد ، مزایای زیادی در دیتاسنترها دارد . برای مثال اگر یک هاست از نظر سخت افزاری نیاز به بررسی و ارتقا داشته باشد با قابلیت vMotion کلیه سرورهای مجازی آن را به هاست دیگری منتقل می کنیم و هاست مورد نظر را از VM خالی می کنیم . در این صورت به راحتی می توانیم عملیات maintenance سرور فیزیکی را انجام دهیم . پس از انجام maintenance نیز می توانیم مجددا VM ها را از طریق vMotion به هاست خودمان منتقل کنیم .

vmotion2

یکی دیگر از مزایای vMotion استفاده متعادل از منابع هاست های ESXi می باشد . فرض کنید دو عدد هاست داریم و مجموعا دو عدد VM نیز بر روی یک هاست وجود داشته باشد . با این تصور بر روی یک هاست دو عدد VM وجود دارد که بر سر منابع از جمله ram و cpu و network و … رقابت می کنند و بر روی هاست دیگر نیز هیچ VM ای نداشته باشیم . این رقابت ممکن است تا جایی ادامه یابد که ، هاست مورد نظر منابع کافی برای ارائه و در اختیار قرار دادن VM ها نداشته باشد و این اتفاق performance را تا حد زیادی در سرویس دهی پایین خواهد آورد . در این حالت جهت رفع مشکل به وسیله vMotion می توانیم یکی از VM ها را به هاست دیگری که منابع بلا اسفاده جهت ارائه به VM دارد ، منتقل کنیم . در مجموع همانطور که پیش بینی می شود یک تعادل در مصرف منابع بین هاست ها ایجاد می شود که در کارایی شبکه مجازی سازی شده تاثیر بسزایی خواهد داشت .

اگر بخواهیم کمی دقیق تر بررسی کنیم ، زمانی که vMotion برای یک VM رخ دهد ، در واقع عمل اختصاص سخت افزار برای VM درون هاست جدید صورت می پذیرد و منابعی از جمله memory  و cpu از هاست جدید به VM اختصاص داده می شود. نکته ضروری و کلیدی و پیش نیاز جهت عمل vMotion ، وجود shared storage می باشد . در هنگام vMotion همه منابع یک VM منتقل می شود و در هاست دیگر به VM اختصاص داده می شود بجز Storage . جهت انجام vMotion نیاز می باشد تا تک تک هاست ها به یک storage مشترک دسترسی داشته باشند و همزمان این مسیر را ببینند .

Shared Storage 1

vSphere Storage vMotion

در مواقعی ما می توانیم بدون انتقال memory و یا cpu مربوط به یک VM ، از یک هاست به هاست دیگر ، تنها Storage یک VM را منتقل کنیم و عمل migration تنها برای storage ماشین مجازی صورت گیرد . در این حالت نیز عمل Storage vMotion می تواند در حالت روشن برای VM صورت گیرد و سرویس دهی همچنان توسط ماشین مجازی صورت پذیرد .

storage vmotion

همانطور که در شکل می بینید VM مورد نظر پس از SvMotion همچنان منابع را از سرور ESXi قبلی دریافت می کند اما Storage مربوط به VM به datastore آبی رنگ منتقل شده است .

به مرور زمان ممکن است یک Storage که محل نگهداری تعدادی VM می باشد ، دچار محدودیت ظرفیت شود و فضای کمی برای ذخیره سازی داشته باشد . در این حالت ممکن است با پر شدن این فضا Performance و کارایی VM ها دچار مشکل شود . در این مواقع برای بهبود وضعیت Storage vMotion به ما کمک می کند تا به راحتی فضای ذخیره سازی تعدادی از VM ها را تغییر دهیم و به Storage های دیگری در سطح شبکه منتقل کنیم.

این نکته را مد نظر داشته باشید که وقتی صحبت از vSphere و مجازی سازی می شود ، پیش نیاز و یکی از رکن های اساسی پیاده سازی این بستر ، Share Storage ها می باشند. Share Storage ها از پروتکل ها و تکنولوژی های مختلف استفاده می کنند که در آینده آن ها را بررسی خواهیم کرد .

 

vSphere Distributed Resource Scheduler

همانطور که اشاره شد vMotion به صورت دستی صورت می پذیرد و به اختیار و حضور ما نیاز می باشد تا vMotion برای یک VM صورت پذیرد . Distributed Resource Scheduler یا به اختصار DRS قابلیتی می باشد تا عمل vMotion به صورت اتوماتیک برای VM ها در صورت نیاز رخ دهد . اگر بخواهیم بررسی دقیق تری داشته باشیم ، میتوان به این موضوع اشاره کرد که vMotion در کنار DRS تکمیل می شود . در محیط مجازی VMware مفهومی تحت عنوان Cluster داریم که با مفهوم عملیات Clustering در سرورهای مایکروسافتی متفاوت است . هنگامی که کلاستری ایجاد می گردد ، تعدادی هاست ESXi عضو این کلاستر می شوند و منابع کلیه هاست های عضو این مجموعه یک pool از منابع را تشکیل می دهند و این pool که شامل همه منابع هاست ها می باشد در اختیار VM هایی قرار میگیرد که در این کلاستر ساخته می شوند .

با توجه به اینکه پس از تشکیل یک کلاستر مقدار memory و cpu کلاستر ، مجموع cpu و memory کلیه هاست های عضو این کلاستر می باشد اما این نکته را باید توجه داشت که یک VM که عضو این کلاستر است ، نمی تواند همزمان مقداری memory یا cpu از یک هاست و مقداری دیگر از از یک هاست دیگر استفاده کند . یک VM در آن واحد و در لحظه ، تنها می تواند منابعی از یک هاست را در اختیار بگیرد و این نکته ای است که حتما باید روی آن دقت شود .

برای روشن شدن این موضوع یک مثال را با هم بررسی می کنیم . فرض کنید دو عدد سرور ESXi داریم و هرکدام ۳۲ گیگابایت حافظه دارند . کلاستری تشکیل می دهیم و این دو هاست را عضو کلاستر می کنیم و قابلیت DRS را نیز برای این کلاستر فعال میکنیم . مسئله ای که مشهود است کلاستر مورد نظر ما مجموعا ۶۴ گیگابایت حافظه خواهد داشت . زمانی که VM ای ساخته می شود در این حالت بیش از ۳۲ گیگابایت حافظه نمی تواند داشته باشد ، چون همانطور که گفته شد این VM همزمان نمی تواند ۳۲ گیگ حافظه از یک هاست و مابقی را از هاست دوم داشته باشد .

زمانی که یک VM در DRS Cluster روشن شود و شروع به کار کند ، این ماشین مجازی در هاستی قرارمی گیرد که بهترین شرایط را برای VM فراهم کند و از این بابت می توان گفت DRS به صورت هوشمندانه از وضعیت مصرف منابع هاست ها مطلع می باشد در هر لحظه ، و VM را در هاستی روشن می کند که شرایط بهتری از نظر منابع داشته باشد .

DRS در زمانی که VM ها روشن می باشند نیز محل قرار گیری آن ها را مانیتور می کند . در صورتی که در کلاستر مورد نظر یکی از هاست ها مصرف بالای منابع داشته باشد DRS به صورت هوشمندانه تشخیص می دهد و VM هایی را از این هاست با vMotion به صورت اتوماتیک به هاست دیگری که مصرف منابع کمتری دارد ، انتقال می دهد . در واقع DRS تعادل مصرف منابع را بین هاست های یک کلاستر برای ما فراهم می کند .

DRS1

 

vSphere Storage DRS

به نوعی می توان Vsphere Storage DRS را که به اختصار SDRS می نامیم ، همان DRS اما در لول Storage ها نام برد . در قسمت قبلی متوجه شدیم که DRS در بالانس کردن cpu و memory بین هاست های یک Cluster موثر است . SDRS نیز در سطح Storage ها وظیفه بالانس کردن و تعادل ظرفیت و کارایی بین Storage ها را برقرار می کند .

Storage DRS نیز مشابه DRS به صورت هوشمندانه عمل می کند و virtual disk های مربوط به ماشین مجازی را با توجه به شرایط  بر روی Storage ای مناسب قرار می دهد . جهت عملیات SDRS نیز باید کلاستری تحت عنوان Datastore Cluster ایجاد گردد که مختص Storage ها می باشد . زمانی که ما یک VM جدید ایجاد می کنیم در مراحل ساخت مشخص می کنیم که از کدام DataStore Cluster استفاده کند . در ادامه Storage ِ DRS به صورت اتوماتیک و هوشمندانه virtual disk های VM را در داخل کلاستر و Storage مناسب ایجاد می کند .

SDRS1

همانطور که اشاره شد DRS از vMotion استفاده می کند برای حفظ تعادل استفاده از منابع در هاست های یک کلاستر . Storage DRS نیز از Storage vMotion جهت متعادل کردن مصرف بین Storage های کلاستر مربوط به Storage و کارایی و … استفاده می کند .

SDRS2

 

vSphere High Availability

یکی از موضوعات اساسی در ساختار مجازی سازی high avasilability می باشد . فرض کنیم ساختاری داریم که هنوز به سمت مجازی سازی پیش نرفته است و هنوز از سرورهای فیزیکی که هر کدام برنامه و سرویس خاصی ارائه می دهند در شبکه استفاده می کنیم . در همان ابتدای کار که بررسی بین ساختار فعلی که فیزیکی می باشد و ساختار مجازی صورت دهیم ، یک سوال مهم و اساسی ممکن است ذهن ما را مشغول کند . در ساختار فیزیکی اگر یک سرور فیزیکی دچار مشکل شود و down شود ، تنها یک سرویس و برنامه ای که ارائه می دهد دچار مشکل خواهد شد ، در صورتی که در ساختار مجازی اگر سرور فیزیکی ما که همان host یا esxi می باشد دچار مشکل شود و Down شود ، تکلیف سرور های مجازی که درون آن جای گرفته اند چه می شود . آیا تعدادی سرور مجازی از سرویس دهی خارج خواهند شد تا زمانی که هاست را رفع عیب کنیم ؟ آیا کلیه برنامه هایی که بر روی سرور های مجازی می باشد به واسطه خاموشی و خرابی هاست دچار مشکل می شوند ؟

HA1

با این شرایط که روزی یک هاست دچار مشکل شود ، باید به دنبال راه حلی باشم تا سرویس هایی که در ماشین های مجازی ما در دل آن هاست موجود است ، دچار مشکل نشوند و همچنان سرویس دهی به کاربران ادامه یابد . اینجا قابلیت vSphere High Availability یا به اختصار HA  به ما یاری خواهد رساند .

با ایجاد هر مشکلی در هاست ESXi و تشخیص Down بودن هاست ، کلیه VM هایی که در سرور فیزیکی ESXi وجود دارند ، به صورت اتوماتیک منتقل می شوند به هاستی دیگر و درآن هاست مجددا روشن می شوند و به سرویس دهی به کاربران ادامه خواهند داد . جهت استفاده از قابلیت HA نیز باید کلاستری از هاست های ESXi تشکیل شود و برای آن کلاستر این قابلیت را فعال کنیم .

HA2

این نکته رو در نظر داشته باشیم که HA بر خلاف DRS از تکنولوژی vMotion استفاده نمیکند تا یک سرور را از یک هاست به هاست دیگر منتقل کند . vMotion در حالتی استفاده می شود که هر دو هاست مبدا و مقصد در شبکه در دسترس و روشن باشند . HA در مواقعی به ما کمک می کند که بدون برنامه قبلی و ناگهانی یک هاست در دسترس نباشد و down شود و در این حالت فرصتی برای vMotion برای ما باقی نمی ماند . (از آنجایی که vMotion نیاز دارد تا هاست مبدا نیز روشن باشد)

وظیفه اصلی HA مراقبت از VM ها نیست که دائما آن ها را چک کند و در صورت down شدن VM آن را در هاست دیگری روشن کند . با این وجود HA می تواند VM ها را نیز مانیتور کند و در صورتی که تشخیص دهد یک VM پاسخگو نیست آن را در هاست دیگری روشن کند ، که به این بررسی VM ها نیز VM Failure Monitoring گفته می شود .

باید دقت کنیم زمانی که HA رخ می دهد ، به مدت زمان یک روشن و restart شدن سرور مجازی ، سرویس دهی قطع می شود . پس به مدت یک restart قطعی و  downtime خواهیم داشت . گاهی مواقع سرویسی که یک سرور مجازی ارائه می دهد آن قدر مهم و حیاتی می باشد که HA و مقدار downtime مربوطه ممکن است برای ما مفید نباشد .

همانطور که قبلا هم اشاره شد جهت استفاده از قابلیت هایی مشابه HA نیاز به share storage خواهد داشت .

vSpher Fault Tolerance

در صورتی که downtime که به مدت یک restart در VM می باشد برای ما قابل قبول نباشد و سرویس حساسی ارائه شده باشد ، می توانیم از قابلیت دیگری استفاده کنیم که بدون downtime ( در صورت خرابی و مشکل در هاست ) در هاست دیگری سرویس دهی ادامه یابد . این قابلیت را تحت عنوان vSphere Fault Tolerance یا به اختصار FT  خواهیم شناخت .

FT یک نسخه از VM را به عنوان Secondary بر روی هاست دیگری نگهداری می کند و در صورت بروز مشکل برای VM اصلی یا همان primary VM ، ادامه سرویس دهی را secondary VM بر عهده خواهد گرفت و این اتفاق بلافاصله و بدون downtime صورت می پذیرد . نام دیگر primary VM تحت عنوان Protected VM و نام دیگر Secondary VM تحت عنوان Mirrored VM می باشد .

FT1

اشاره شد که با از کار افتادن هاستی که primary VM در آن است بلافاصله Secondary VM سرویس دهی راشروع می کند . به محض اینکه Secondary VM سرویس دهی راشروع کند ، نقش Primary را به خود می گیرد و یک VM دیگر در هاستی دیگر ساخته خواهد شد تا نقش Secondary را بگیرد . با ساخته شدن مجدد Secondary VM این اطمینان خاطر برای ما ایجاد می شود که Primary VM همواره در امنیت و محافظت خواهد بود .

اگر به صورت همزمان نیز هر دو هاست مربوط به Primary VM و Secondary VM دچار مشکل شوند ، در این صورت توسط قابلیت HA می توان Primary VM را در هاست سومی در شبکه restart کرد تا مجددا سرویس دهی VM شروع به کار کند .بدیهی است که پس از شروع به کار Primary VM مجددا سیستم Secondary VM در هاست چهارمی در شبکه ایجاد خواهد گردید .

محدودیتی که تا قبل از vSphere6 جهت FT وجود داشت ، محدودیت تک vCPU برای VM مورد نظر بود . یعنی قابلیت FT تنها برای VM هایی قابل پیاده سازی بود که تنها یک vCPU داشتند و این مسئله تا حدی باعث شده بود تا کمتر از FT استفاده شود . در vSphere 6 و Hypervisor ESXi 6 این قابلیت بهبود یافته و حداکثر تا ۴ عدد vCPU را پشتیبانی می کند .

در مورد ساختار و معماری کار FT قطعا در آموزش مختص به این موضوع بیشتر صحبت خواهیم کرد .

همانطور که در این قسمت متوجه شدیم ، سرورهای Primary و Secondary دقیقا مشابه هم می باشند و این انتقال اطلاعات از مکانیزم هایی جهت همسان سازی اطلاعات استفاده می کند که قطعا در مقالات این موضوع مورد بررسی قرار خواهیم داد .

 

vSphere Storage APIs for Data Protection and VMware Data Protection

 

یکی از اساسی ترین جنبه های هر ساختار شبکه ای ، فارق از اینکه شبکه فیزیکی طراحی شده باشد یا مجازی سازی صورت گرفته باشد ، مبحث Backup گیری و Disaster Recovery می باشد . جهت بک آپ گیری صحیح و فراهم کردن امکان آن در محیط مجازی سازی شده با VMware ود جزء اصلی در vSphere 6 وجود دارد .

  • vSphere Storage APIs for Data Protection (VADP)
  • VMware Data Protection

vSphere Storage APIs یک رابط نرم افزاری (Application Programming Interface) از VMware می باشد تا محصولات third-party مربوط به شرکت های ارائه دهنده Storage و محصولات بک آپ گیری ، به راحتی محصولاتشان با محیط مجازی سازی شده VMware همخوانی داشته باشد . در واقع محصولات این شرکت ها با محیط مجازی سازی شده به راحتی می توانند کار کنند و خود را با این محیط integrage کنند . شاید دوستانی که قبلا تجربه کار با محیط مجازی را داشته اند با محصولاتی از جمله Veeam Backup and Replication و Backup exec و … جهت بک آپ گیری از VM ها استفاده کرده باشند . چون اینچنین محصولاتی که شرکت های دیگر تولید کننده آنها می باشند به راحتی بتوانند با محیط مجازی سازی شده کار کنند ، vSphere Storage API ها به ما کمک می کنند . VADP نیز مجموعه ای از این API ها می باشد جهت امکان بک آپ گیری و بازگردانی اطلاعات بک آپ گرفته شده . VADP یک رابط است و امکان بک آپ گیری را با دیگر برنامه ها برای ما فراهم می کند و در واقع خودش نمی تواند بک آپ گیری و بازگردانی برای ما انجام دهد .

همانطور که اشاره کردم برنامه های مختلفی برای بک آپ گیری از VM ها وجود دارد . شرکت VMware نیز محصولی جهت بک آپ گیری از VM ها با نام VMware Data Protection یا به اختصار VDP ایجاد کرده است . قبل از vSphere 5.1 نیز شرکت VMware از محصولی با نام VMware Data Recovery(VDR) استفاده می کرد که به لطف VDP از نسخه vSphere 5.1 به بعد VDR حذف گردید . سیستم VDP خودش یک VM می باشد که در یکی از هاست های ما ایجاد خواهد شد (یک Virtual Appliance می باشد) و عملیات بک آپ گیری از دیگر VM ها را بر عهده خواهد داشت .

VDP1

 

 

Virtual SAN (VSAN)

VSAN قابلیت جدیدی می باشد که شرکت VMware چند سالی بر روی آن سرمایه گذاری کرده است . از vSphere 5.5 به بعد این قابلیت اضافه گردیده و از قابلیت های جدید vSphere محسوب می شود . با وجود اینکه این قابلیت در داخل پکیج vSphere موجود می باشد اما برای استفاده از آن نیاز به تهیه لایسنسی مجزا برای VSAN می باشد .

VSAN مجموعه ای از Storage های Local مربوط به سرورهای ESXi را با هم تجمیع کرده و یک SAN مجازی از آن ها ایجاد می کند و در اختیار ما قرار می دهد . VSAN یک Software Defined Storage(SDS) محسوب می شود که در مقالات بعدی به صورت مفصل در مورد SDS ها صحبت خواهیم کرد . جهت راه اندازی VSAN حداقل ۳ عدد هاست نیاز می باشد و به این طریق می توانیم هاردهای Local سرورهای فیزیکی را با یکدیگر تجمیع کرد و یک SAN مجازی ایجاد کرد که به صورت Share Storage در شبکه در دسترس سرورها قرار خواهد گرفت .

فرض کنیم تعدادی هاست (۳ عدد و یا بیشتر) در شبکه داریم که این هاست ها نیز دارای هاردهای لوکال باشند . این هاردهای لوکال تنها برای خود هاست در دسترس می باشند و به عنوان Datastore تنها توسط همان هاست استفاده می شوند . VSAN به ما این امکان را می دهد تا تمامی هاردهای لوکال هاست های مورد نظر با هم در قالب یک SAN مجازی تشکیل این Share Storage را دهند و این کار باعث می شود ما یک SAN داشته باشیم تا در شبکه هاست های مورد نظر به راحتی از آن استفاده کنند . در این SAN ، کلیه اطلاعات به صورت توزیع شده بر روی هاردهای لوکال هاست ها ذخیره می گردد . این نکته نباید فراموش شودکه هر هاست باید دارای حداقل یک عدد هارد از نوع Solid-State Storage یا Solid-State Drive باشد که به اختصار تحت نام SSD می شناسیم . هاردهای SSD جهت بهبود کارایی I/O (عملیات ورودی و خروجی و خواندن و نوشتن) مورد استفاده قرار می گیرند .

VSAN1

VSAN از الگوریتم هایی جهت محافظت از اطلاعات استفاده می کند و اطمینان پیدا می کند تا اطلاعات بر روی حداقل دو عدد هاست وجود داشته باشد . در این صورت با خرابی یک هاست از صحت وجود اطلاعات و ادامه سرویس دهی به کاربران مطمئن خواهیم بود .

در مقالات مرتبط با VSAN در آینده با نحوه پیاده سازی ، نوع انتخاب تجهیزات و … آشنا خواهیم شد .

 

 

vSphere Replication

این قابلیت وظیفه Replication دیتا را برعهده دارد . در vSphere 5.0 قابلیت vSphere Replication تنها در کنار Site Recovery Manager (SRM) استفاده می شد و از نسخه vSphere 5.1 به بعد از SRM جدا شد و بدون وابستگی به آن جهت Replication دیتا مورد استفاده قرار گرفت . vSphere Replication این امکان را برای ما فراهم می کند تا عمل Replication مربوط به VM ها را از یک محیط vSphere به محیط vSphere دیگری به راحتی انجام دهیم . اگر بخواهیم دقیق تر بیان کنیم ، یعنی ما می توانیم VM های خود را از یک دیتاسنتر به دیتاسنتر دیگری Replicate کنیم . اصولا به دیتا سنتر اول Primary Datacenter و یا Production Datacenter گفته می شود و به دیتا سنتر دوم که VM ها در آن Replicate می شوند Secondary Datacenter ، Backup Datacenter و یا(DRS) Disaster Recovery سایت گفته می شود .

vSphere replication1

بر خلاف Replication هایی که بر اساس Hardware-Based می باشند ، vSphere Replication بر اساس هر VM می تواند تنظیم شود و می توانیم جهت Replication بین سایت ها ، مشخص کنیم چه VM یه workload هایی Replicate شوند و چه workload هایی Replicate برایشان صورت نگیرد .

جهت Replication بین دو سایت می توان از Replication بین SAN Storage ها نیز استفاده کرد که هزینه بر خواهد بود ، پس روش Built-in مربوط به vSphere که vSphere Replication می باشد مقرون به صرفه و مفید خواهد بود . روش نصب vSphere Replication نیز از طریق نصب یک Virtual Appliance می باشد که در مقاله مخصوص vSphere Replication کاملا بررسی خواهد شد .

دوستان گرامی ، با مقالات ارائه شده تا این قسمت تا حدودی با محیط مجازی سازی شرکت VMware آشنا شدیم و برخی قابلیت ها را بررسی کردیم . گرچه خیلی موارد جهت آشنایی به بحث و توضیحات بیشتری دارد که در این مقالات بیان نشد از جمله موارد مربوط به Storage ها ، که قطعا در مقالات بعدی با همه این موارد آشنا خواهیم شد . با LearnExpert همراه باشید تا در کنار هم بیشتر با VMware virtualization آشنا شویم .

 

نویسنده : محمدرضا ملک احمد

 

 

 

 

 

(۲) نظر

  1. بازتاب: نصب VMware ESXi |

ارسال یک نظر

آدرس ایمیل شما منتشر نخواهد شد. گزینه‌های ضروری با علامت مقابل نشانه‌گذاری شده‌اند *

شما می‌توانید از این تگ‌های HTML استفاده نمائید: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>