Real Time Web Analytics

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

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

Upgrade به ورژن VMware vSphere 6.7 (بخش دوم)

با سلامی مجدد خدمت دوستان
با ادامه سری مقالات Upgrade به ورژن vSphere 6.7 ، به مرحله اول یا Pre-Upgrade رسیدیم . در مقاله اول از Upgrade به ورژن VMware vSphere 6.7 برخی مزایای ورژن جدید را بررسی کردیم و در این قسمت باید مواردی که قبل از آپگرید نیاز به توجه دارند را بررسی کنیم . این امکان وجود دارد که ما محصولات مختلفی از vSphere در زیرساخت خودمان استفاده کرده باشیم و حتی نرم افزارهای جانبی مختلفی که وابسته به زیر ساخت مجازی ما باشند را در شبکه داشته باشیم . پس قبل از شروع به آپگرید باید Release Note و Documentation مربوط به این محصولات رو حتما مطالعه کنیم و همچنین در مورد محصولات VMware باید حتما Interoperability Matrices و VMware Compatibility Guide رو بررسی کنیم و وابستگی های سخت افزاری و نرم افزاری را استخراج کنیم تا مشکلی در آپگرید نداشته باشیم .مورد دیگر جهت بررسی قبل از آپگرید Third-Party Solution ها و سازگاری آن ها خواهد بود با ورژن جدیدی که مد نظر ما میباشد . یکی دیگر از موارد قبل از Upgrade ، بررسی سلامت وضعیت فعلی زیر ساخت vSphere ما است که این مرحله تحت عنوان health check نیز شناخته میشود . در ادامه با هر یک از این موارد بیشتر آشنا میشویم .

Product Release Notes

اصولا هر محصولی از جمله محصولات VMware به همراه Release Note آن محصول منتشر میشوند که اطلاعات کلی و راهنمای اصلی محصول است . اصولا قبل از پیاده سازی هر محصولی باید این مورد مطالعه شود و مورد بررسی قرار گیرد . برای مثال میزان منابع مورد نیاز برای راه اندازی محصول و پیش نیازها و وابستگی ها در Release Note بیان میشود . برای مثال اطلاعات زیادی مشابه اطلاعات زیر از Release Note مربوط به vCenter Server 6.7 بدست میاید :

۱ . موارد و قابلیت های جدید vCenter Server 6.7
2 . اطلاعات مربوط به ورژن های قبلی و ارجا دادن به Release Note های ورژن های قبلی
۳ . اطلاعاتی در خصوص Patch های این نسخه و ارجا به VMware Knowledge Base جهت اطلاعات بیشتر Patch ها مثل filename یا build یا سایز دانلود و checksum و …
۴ . اطلاعات مربوط به آپگرید یا Migration و بررسی حالت هایی که امکان پذیر نیست برای مثال ارتقا از نسخه ۶٫۵ U2 به ۶٫۷ اشاره شده که امکان پذیر نیست .
۵ . بررسی مشکلات احتمالی و ایرادات امنیتی و ..

پس با این مثال متوجه میشویم که بررسی Release Note محصولات قبل از آپگرید به ما خیلی کمک خواهد کرد .


Product Documentation

همیشه باید این اطمینان را داشته باشیم که Documentation مربوط به محصول را در هنگام نصب یا آپگرید یا مراحل نصب Patch ، مطالعه کرده ایم . اصولا در Documentation مربوط به محصولات VMware مستقیما لینک هایی به Release Note ها وConfiguration Maximum ها و راهنماهای آپگرید و … وجود دارد .


Interoperability Matrices

یکی از اساسی ترین فاکتورهایی که قبل از آپگرید باید بررسی شود ، Interoperability Matrices میباشد که یکی از کلیدهای ارتقای موفقیت آمیز است . این ابزار کمک میکند تا سازگاری ورژن های مختلف محصولات VMware چک شود . در واقع قبل از ارتقا بررسی میکنیم که ورژن محصولات فعلی آیا با ورژنی که ما میخواهیم آپگرید کنیم همخوانی دارد یا خیر . این نکته را باید دقت کنیم که ۳ نوع Interoperability Matrices وجود دارد . این سه نوع شامل Database ، Product و Upgrade Path میشوند .

نوع اول (Product) : کار اصلی Product Interoperability Matrix این است که بررسی کند ورژن دو نوع محصول VMware با یکدیگر سازگار می باشد یا خیر . یعنی این دو محصول با ورژن هایی که دارند (یا قرار است داشته باشند) میتوانند کنار هم کار کنند یا ناسازگار خواهند بود . برای مثال میتوانیم چک کنیم که آیا vCenter Server 6 Update 3 میتواند در کنار Site Recovery Manager ورژن ۸٫۱ کار کند یا خیر ؟ پس جواب این سوال به وسیله Product Interoperability Matrces بدست می آید .

Product Interoperability Matrices


نوع دوم (Database) : زمانی که یک طراحی و Solution و محصولی در VMware نیاز به دیتابیس خارجی داشته باشد برای پیدا کردن ورژن و edition مناسب و سازگار باید از Database Interoperability Matrices استفاده کنیم . برای مثال اگر این سوال برای ما مطرح باشد که آیا میتوان برای نصب vCenter Server از Microsoft SQL Server 2016 استفاده کرد یا خیر .

Database Interoperability Matrices



نوع سوم (Upgrade Path) : در صورتی که بخواهیم محصولی را به صورت in-place بخواهیم آپگرید کنیم Upgrade Path Interoperability Matrices میتوانیم مشاهده کنیم بین چه ورژن هایی از آن محصول امکان ارتقا وجود دارد . پس در اینجا تنها با یک محصول یا Solution طرف هستیم و ماتریکسی از همان محصول برای ما نمایش داده میشود که از ورژن فعلی تا چه ورژنی میتوانیم ارتقا را انجام دهیم . برای مثال شاید برای ما سوال باشد که آیا vCenter Server 6.5 Update 2 آیا امکان ارتقا به vCenter Server 6.7 را به صورت یکجا و با یکبار عملیات آپگرید ، را دارد یا خیر ؟ اگر محصولی مستقیما به ورژن دلخواه ما قابل ارتقا نباشد در ماتریکس ارائه شده میتوانیم ببینیم ابتدا به چه ورژنی میتوان ارتقا داد که پس از آن قابل ارتقا به ورژن مورد نظر ما باشد (دو مرحله آپگرید) . نهایتا با این ماتریکس مسیر آپگرید برای ما مشخص خواهد شد که با یک مرحله آپگرید امکان ارتقا به ورژن دلخواه وجود دارد یا بیش از یک آپگرید نیاز است .

Upgrade Path Interoperability Matrices


VMware Compatibility Guide

شاید برای خیلی از ما مشکلات مربوط به درایورها یا Firmware ها به علت سازگار نبودن در محیط vSphere پیش آمده باشد . برای مثال اگر قرار باشد سرورهای ESXi را آپگرید کنیم نیاز هست سخت افزار سرورها با ورژن ESXi همخوانی و سازگاری داشته باشند و برای چک کردن این موضوع میتوانیم از ابزار VMware Compatibility Guide استفاده کنیم . در این خصوص قبلا در ویدیو VMware Compatibility Guide این ابزار تا حدودی آموزش داده شده است و برای آشنایی با این ابزار میتوانید از آن استفاده کنید . ناگفته نماند در مقاله ای جداگانه نحوه استفاده از vSphere Assessment Tool را بررسی کردیم که قبل از آپگرید در شناسایی محیط و امکان ارتقا به ما کمک فراوانی خواهد کرد .

Third-Party Solution Compatibility

ممکن است محصولات Third-Party از vendor های مختلف در شبکه داشته باشیم که به محیط و سرویس های vSphere ما وابستگی داشته باشند . برای مثال محصولات بک آپ گیری و مانیتورینگی که جهت محیط vSphere استفاده میکنیم ، ممکن است از محصولات VMware نباشد . به عنوان نمونه ممکن است از برمانه Veeam Backuo and Replication برای بک آپ گیری از محیط vSphere استفاده کنیم . در این مواقع نیز با بررسی بیشتر این محصولات باید سازگاری آن ها را قبل از عملیات آپگرید ، با ورژن جدید چک کنیم تا در نرم افزارهای Third-Party دچار مشکل نشویم .

Health Checks

قبل از عملیات آپگرید بهتر است سلامت وضعیت vSphere را در وضعیت فعلی بررسی کنیم . اگر محیط vSphere ما از نظر سلامت سرویسی دچار مشکل باشد ممکن است در هنگام آپگرید با مشکل مواجه شویم و نیاز به rollback داشته باشیم . در بسیاری از مواقع مشکلاتی نظیر مشکلات DNS یا NTP یا کمبود ظرفیت Storage و … در سرویس های vSphere مشکل ایجاد میکنند که موارد این چنینی اگر اصلاح نشوند ممکن است در هنگام آپگرید نیز دردسرساز شوند . پس توصیه VMware این است که عملیات health check را با ابزارهایی نظیر vRealize Operations یا vCheck vSphere و … انجام دهیم . در صورت وجود پشتیبانی هم میتوانیم از VMware Partner نیز برای این کار کمک بگیریم .

Backing Up Environment

یکی از اساسی ترین کارهایی که قبل از آپگرید باید انجام دهیم ، عملیات بک آپ گیری میباشد . در مورد بک آپ گیری همیشه باید اطمینان حاصل کنیم که بک آپ صحیح گرفته ایم که واقعا قابل بازیابی باشد . شاید در نگاه اول به نظر برسه که خوب ما باید Platform Service Controller و vCenter را تنها بک آپ تهیه کنیم در حالی که باید در صورت امکان از همه کامپوننت های موجود بک آپ تهیه کنیم . به عنوان مثال باید از تنظیمات ESXi و Distributed Virtual Switch (درصورت وجود) و product های دیگر در صورت وجود مثل VMware NSX و Horizon و … بک آپ تهیه کنیم .
در خصوص vSphere Appliance در نسخه های ۶٫۵ یا ۶٫۷ توصیه VMware این است که به صورت built-in و File-Base اقدام به Backup گیری کنیم . در صورتی که vCenter به صورت ویندوزی پیاده سازی شده است توصیه میشود از برنامه های Backup گیری استفاده کنیم که image-based کار میکنند . البته این نکته را باید در نظر داشته باشیم که در Migration یا Upgrade مربوط به vCenter Server اگر با مشکلی مواجه شویم عملیات rollback اتفاق میوفتد و نیازی به restore کردن ما نیست . (با وجود rollback باز هم توصیه میشود Backup تهیه شود) در این خصوص اگردر حال عملیات Migrating از vCenter Server ویندوزی به vCenter Server Appliance یا همان VCSA هستیم و مشکلی پیش بیاید که rollback اتفاق بیوفتد ، در ابتدا VCSA که جدید Deploy شده است بایدخاموش شود و از داخل Inventory پاک شود . سرور vCenter ویندوزی قبلی روشن شود و مجددا به اکتیو دایرکتوری جوین شود . در خصوص Upgrade مربوط به VCSA هم قضیه به همین گونه است ، یعنی در صورت بروز مشکل جهت عملیات rollback باید Appliance جدید را خاموش کنیم و Appliance اصلی و قبلی را روشن کنیم .
بالاتر اشاره شد در مورد ESXi نیز باید Configuration را Backup بگیریم ، تا در هنگام بروز مشکل در Upgrade یا Patching مربوط به ESXi اگر هاست failed شد بتوانیم تنظیمات ESXi را بازیابی کنیم . (عملیات بک آپ گیری از تنظیمات هاست از طریق CLI tools امکان پذیر است)

با من همراه باشید تا در مقاله بعدی مراحل مربوط به Upgrade رو شروع کنیم .

منبع : vSphere Blogs
محمدرضا ملک احمد
Malekahmad.it@gmail.com

ارسال یک نظر

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

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