منظور از Site Recovery Manager یا SRM چیست، بررسی ویژگی ها و مزایای آن – قسمت چهارم

در قسمت اول مقاله بررسی فنی Site Recovery Manager یا SRM در مورد ویژگی ­های SRM صحبت کردیم و با برخی اصطلاحات در این زمینه آشنا شدیم. در قسمت دوم در مورد Disaster   recovery  و همچنین راه هایی برای جلوگیری از Disaster گفته شد، در قسمت سوم به بررسی Inventory Mapping پرداختیم و شرح Protection Groups بیان شد حال به ادامه موضوع خواهیم پرداخت.

همسان‌سازی مبتنی بر Array

ماشین‌های مجازی که در گروه‌های حفاظت همسان‌سازی مبتنی بر Array وجود دارند توسط Storageی مشخص می‌شوند که ماشین‌های مجازی روی آن قرار دارند. تمام ماشین‌های مجازی روی یک Datastore باید توسط ویژگی ­های SRM

محافظت شوند و همگی باید به گروه محافظتی یکسانی تعلق داشته باشند.  به‌هیچ ‌عنوان پیشنهاد نمی‌شوند که از زیرمجموعه‌ای از ماشین‌های مجازی روی یک Datastore حفاظت گردد و این امر تحت پشتیبانی نیست. انجام این کار هشدارهایی را در رابط کاربری SRM فعال می‌کند و می‌تواند منجر به مشکلاتی اساسی در آن ماشین‌های مجازی حفاظت نشده می شود. در مثال زیر، ماشین‌هایی مجازی دیده می‌شود که روی چندین Datastore قرار دارند که به LUNها و گروه‌های Consistency و گروه‌های حفاظتی Map می‌گردند. در Storage Array می‌توان چندین LUN را در یک گروه Consistency تنظیم کرد تا از تداوم ترتیب Write اطمینان حاصل شود. گفته می‌شود که این Datastoreها در یک گروه قرار دارند که حاوی تمام Datastoreهایی است که به ماشین‌های مجازی در یک گروه حفاظتی مرتبط هستند.

نگاهی به Virtual Volumeها

یکپارچه‌سازی SRM با Virtual Volumes، مضاف بر قابلیت همسان‌سازی ساخته می‌شود که در Virtual Volumes 2.0 معرفی شد. این پیاده‌سازی مفاهیم گروه‌های همسان‌سازی و Fault Domainها را معرفی کرد که یکپارچه‌سازی SRM به آن اضافه می‌کند. یک Fault Domain را می‌توان به‌طور تقریبی معادل یک سایت یا یک جفت همسان‌سازی Array دانست. یک گروه همسان‌سازی که تحت عنوان گروه Consistency هم شناخته می‌شود، از یک یا چند ماشین مجازی تشکیل می‌شود که با نرخ ثابتی همسان‌سازی می‌گردند. یک گروه حفاظتی vVol می‌تواند شامل یک یا چند گروه همسان‌سازی باشد. تمام دیسک‌های ماشین‌های مجازی همسان‌سازی‌شده باید به گروه همسان‌سازی یکسانی تعلق داشته باشند.

ماشین‌های مجازی با مرتبط شدن به پالیسی Storageی که برای همسان‌سازی تنظیم می‌گردد، به یک گروه حفاظتی Volume مجازی اضافه می‌شوند. این امر این امکان را فراهم می‌کند که حفاظت از ماشین‌های مجازی خودکارسازی شده و مبتنی بر Policy باشند.

همسان‌سازی vSphere توسط ویژگی ­های SRM

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

Storage مبتنی بر پالیسی در نگاه و بررسی فنی ویژگی ­های SRM

گروه‌های حفاظتی Storage مبتنی بر پالیسی برای شناسایی Datastoreهای حفاظت شده و ماشین‌های مجازی از vSphere Storage استفاده می‌کنند. آن‌ها فرایند حفاظت و رفع حفاظت از ماشین‌های مجازی و اضافه کردن و حذف کردن Datastoreهای از گروه‌های حفاظتی را خودکارسازی می‌کنند. گروه‌های حفاظتی مبتنی بر پروفایل Storage، یکپارچه‌سازی عمیقی را با ابزار آماده‌سازی ماشین مجازی مثل VMware vRealize Automation ارائه می‌دهند. این ترکیب باعث می‌شود پیاده‌سازی و حفاظت از ماشین‌های مجازی از هر زمان دیگری ساده‌تر باشد.

گروه‌های حفاظتی مبتنی بر پالیسی Storage از Tagهای vSphere همراه با مدیریت مبتنی بر پالیسی vSphere Storage استفاده می‌کنند تا حفاظت مبتنی بر پالیسی خودکارسازی‌شده‌ای را برای ماشین‌های مجازی فراهم نمایند. مدیریت مبتنی بر پالیسی Storage به ادمین‌های vSphere این توانایی را می‌دهد که آماده‌سازی و مدیریت Storage ماشین‌های مجازی را خودکارسازی کنند تا به الزاماتی مثل عملکرد، دسترس‌پذیری و حفاظت پاسخ دهند.

بیشتر بخوانید: بررسی و تحلیل توازن بارهای کاری با vSphere vMotion

Tagهای vSphere توانایی اتصال فراداده به vSphere Inventory که در این مورد Datastoreها هستند را فراهم می‌نماید که این کار باعث می‌شود بتوان Objectها را بهتر تنظیم کرد، بهتر بین آن‌ها جستجو نمود و آن‌ها را به پالیسی‌های Storage مرتبط ساخت.

چگونگی استفاده از Tagها و مدیریت مبتنی بر پالیسی Storage همراه با گروه‌های حفاظتی مبتنی بر پالیسی Storage

• یک Tag ایجاد می‌گردد و به تمام Datastoreها در یک گروه حفاظتی مورد نظر مرتبط می‌شود.
• برای هر گروه حفاظتی که از Tag استفاده می‌کند، یک پالیسی Storage مبتنی بر Tag ایجاد می‌گردد.
• یک گروه حفاظتی مبتنی بر پالیسی Storage ایجاد شده و به پالیسی Storage مرتبط می‌شود.

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

برنامه‌های بازیابی یا Recovery Planها

از ویژگی ­های SRM می توان گفت برنامه‌های بازیابی در SRM مثل یک Runbook خودکارسازی‌شده هستند که تمام مراحل را در فرایند بازیابی کنترل می‌کنند. این برنامه سطحی است که در آن اقداماتی مثل Failover، انتقال برنامه‌ریزی‌شده، تست و حفاظت مجدد Re-Protect نجام می‌گردد. یک برنامه‌ی بازیابی حاوی یک یا چند گروه حفاظتی است و یک گروه حفاظتی می‌تواند در بیش از یک برنامه‌ی بازیابی حضور داشته باشد. این امر انعطافی را برای تست یا بازیابی یک برنامه کاربردی و همچنین تست یا بازیابی یک گروه از برنامه‌های کاربردی یا کل سایت فراهم می‌نماید.

بیشتر بخوانید: بررسی Replication در SRM و vVols

در مثال زیر سه گروه حفاظتی شامل: Web App، Email و و سه برنامه‌ی بازیابی شامل برنامه‌ی بازیابی Web App که حاوی گروه حفاظتی Web App است وجود دارد ، برنامه‌ی بازیابی Email که حاوی گروه حفاظتی Email است و برنامه‌ی بازیابی Whole Site که حاوی هر سه گروه حفاظتی می‌باشد.

گروه‌های اولویت در بررسی فنی ویژگی ­های SRM

پنج گروه اولویت در Site Recovery Manager وجود دارند، ماشین‌های مجازی در گروه اولویت اول از همه بازیابی می‌شوند، سپس ماشین‌های مجازی در گروه اولویت دو بازیابی می‌گردند و به همین ترتیب پیش می‌رود. تمام ماشین‌های مجازی در یک گروه اولویت در زمان یکسانی شروع به کار می‌کنند و گروه اولویت بعدی تنها بعد از اینکه تمام ماشین‌های مجازی شروع به کار پاسخ‌دهی کردند، آغاز می‌شود.

این امر به ادمین‌ها گزینه‌ای برای اولویت‌بندی بازیابی ماشین‌های مجازی می‌دهد. برای مثال مهم‌ترین ماشین‌های مجازی با کمترین RTO معمولاً در اولین گروه اولویت قرار دارند و ماشین‌های مجازی که اهمیت کمتری دارند در گروه‌های اولویت بعدی قرار خواهند گرفت. مثال دیگر در این زمینه، لایه برنامه کاربردی است؛ سرورهای دیتابیس را می‌توان در گروه اولویت دو  قرار داد؛ سرورهای برنامه کاربردی و Middleware در گروه اولویت سه؛ سرورهای Client و وب در گروه اولویت چهار.

مقاله های مرتبط: