محصولات آکو
HPE
DELL
Broadcom
خدمات آکو
بلاگ
دانلود
HPE
DELL
Broadcom
Vmware
درباره ما
ارتباط با ما
پیکربندی و مدیریت Metro Protection در Dell PowerStore؛ قسمت ششم
پیکربندی Metro Protection در Dell PowerStore مجموعهای از تنظیمات مرتبط با Remote System، Host Connectivity، Metro Witness، Metro Volume و مدیریت وضعیت Metro Resource است. پس از ایجاد Metro، مدیر زیرساخت باید بتواند Role سیستمها، وضعیت Synchronization و Actionهایی مانند Pause، Resume، Promote و Demote را نیز بهدرستی مدیریت کند.
این مقاله قسمت ششم مجموعه حفاظت از داده در Dell PowerStore است. در قسمت قبل، مدیریت Replication بررسی شد و در این قسمت تمرکز بهطور کامل روی Metro Protection قرار میگیرد؛ از بررسی پیشنیازها تا مدیریت Protection Policy و QoS روی Metro Resource.
Metro Protection برای Volume و Volume Group در PowerStore قابل استفاده است و Host میتواند Resource را از طریق دو سیستم PowerStore مشاهده کند. برای پیادهسازی صحیح آن باید Remote System، Connectivity مناسب Host و در صورت نیاز Metro Witness پیکربندی شوند. پس از راهاندازی نیز وضعیتهای Preferred، Nonpreferred، Active/Active، Fractured و Paused تعیین میکنند چه Actionهایی روی Metro Resource قابل اجرا هستند.
- مسیر مطالعه این راهنما
- پیشنیازها و محدودیتهای Metro Protection
- پیکربندی Host Connectivity برای Metro
- Metro Witness چگونه کار میکند؟
- پیکربندی Metro Volume
- پیکربندی Metro Volume Group
- تنظیم Metro Role
- مانیتور کردن Metro Resourceها
- عملیات مدیریتی روی Metro Resource
- جدول Actionهای مجاز روی Metro Resource
- استفاده از Protection Policy همراه با Metro
- استفاده از QoS همراه با Metro
- مطالب و محصولات مرتبط
- جمعبندی مدیریت Metro Protection
- سوالات متداول
مسیر مطالعه این راهنما
قسمت قبل: مدیریت Replication در Dell PowerStore؛ قسمت پنجم
قسمت فعلی: مدیریت Metro Protection در Dell PowerStore؛ قسمت ششم
قسمت بعدی: مدیریت Remote Backup در Dell PowerStore؛ قسمت هفتم
پیشنیازها و محدودیتهای Metro Protection
Metro فقط برای Applianceهای PowerStore T Model و PowerStore Q Model پشتیبانی میشود و Metro Protection برای Volume و Volume Group قابل استفاده است.
Hostهای Windows، Linux و VMware ESXi متصل از طریق FC/SCSI یا iSCSI میتوانند در Metro Protection استفاده شوند. پشتیبانی از Hostهای Windows و Linux از PowerStoreOS 4.x فراهم شده است.
برای آمادهسازی ارتباط میان دو PowerStore، ابتدا باید Remote System بهدرستی پیکربندی شده باشد. جزئیات این مرحله در راهنمای پیکربندی Remote System برای حفاظت از داده در Dell PowerStore بررسی شده است.
الزامات Block Metro
هنگام ایجاد Connection با Remote System، PowerStore Configuration سیستم مقابل را شناسایی میکند و Capabilityهای قابل پشتیبانی را فعال میسازد. برای فعال شدن Block Metro Capability باید شرایط زیر روی هر دو سیستم برقرار باشد:
- هر دو سیستم PowerStoreOS 3.x یا جدیدتر اجرا کنند.
- Latency مربوط به Remote System روی Low قرار داشته باشد.
- Data Connection Type برابر TCP باشد.
اگر Local و Remote PowerStore System با Version 3.x یا جدیدتر نصب شده باشند، TCP Connection بهصورت خودکار پشتیبانی میشود.
اگر یکی یا هر دو سیستم Version 2.x داشته باشند، برای فعالسازی Metro باید به 3.x Upgrade شوند. پس از Upgrade، Alert مربوط به Update کردن Connection Type نمایش داده میشود. از Link موجود در Alert میتوان پنجره Update Remote System Transport را باز کرد و سپس Update Transport را اجرا کرد.
پیشنیازهای Metro Witness
Witness باید روی یک Linux Host فیزیکی یا مجازی نصب شود. توصیه شده است این Host در Fault Domain سوم و جدا از دو سیستم PowerStore قرار بگیرد.
| مولفه | الزام |
|---|---|
| Dependency | Java 11 و SQLite |
| CPU Architecture | x64 |
| RAM | حداقل 4 GB |
| Disk | حداقل 5 GB فضای آزاد |
| Port | 443/tcp |
| Network Latency | حداکثر 100 Millisecond روی Management Network میان PowerStore و Witness |
| User Access | root یا sudo |
برای Virtual Witness استفاده از Static IP Address توصیه میشود. اگر DHCP استفاده شود، Witness باید با FQDN به PowerStore اضافه شود.
پیکربندی Host Connectivity برای Metro
Host Metro Connectivity روی هر دو Local و Remote PowerStore System تعریف میشود. نتیجه این پیکربندی آن است که Host و Application میتوانند Volumeهای فیزیکی موجود روی دو سیستم را بهصورت یک Volume مشاهده کنند.
هنگام پیکربندی Metro Connectivity برای Host باید Preferred Array نیز مشخص شود تا تعیین شود در Failure کدام سیستم Storage Access را حفظ کند. Host از نوع ESXi، Windows یا Linux نیز باید روی هر دو Local و Remote System تعریف شده باشد.
| حالت | رفتار Host |
|---|---|
| Host is co-located with this system | Path سیستم Local Latency کمتری دارد و Host تا زمانی که Local System Down نشود، I/O را ترجیحاً به Local System ارسال میکند. |
| Host is co-located with the remote system | Path سیستم Remote Latency کمتری دارد و Host تا زمانی که Remote System Down نشود، I/O را ترجیحاً به Remote System ارسال میکند. |
| Co-located with both systems | Latency و Performance دو Path برابر در نظر گرفته میشود و Host براساس Multipath Considerationهای خود مسیر را انتخاب میکند. |
صرفنظر از Connectivity پیکربندیشده، تمام ESXi Hostها باید روی همان vCenter Cluster قرار داشته باشند.
برای ESXi Hostهای Mapشده به Metro Volume استفاده از Round Robin Path Selection Plugin یا PSP با Latency Mode فعال توصیه شده است. اگر یک سیستم Offline شود و Host وارد APD شود، پیکربندی vSphere HA نیز توصیه شده است.
Metro Witness چگونه کار میکند؟
از PowerStoreOS 3.6 به بعد میتوان Witness Server را به Metro Protection اضافه کرد. Witness یک Third Party غیرفعال است که روی Host مستقل و ترجیحاً در Data Center دیگری قرار میگیرد.
هنگام Failure، Local و Remote PowerStore System با Witness تماس میگیرند و درخواست Fracture شدن Metro Session را ارسال میکنند. Witness تعیین میکند کدام سیستم برای Host در دسترس باقی بماند و I/O را ادامه دهد. در صورت امکان، سیستم دارای Preferred Role در اولویت قرار میگیرد.
Witness Service اطلاعات حیاتی و غیرقابلبازسازی نگهداری نمیکند؛ بنابراین Backup، Save یا Recover کردن آن ضروری نیست.
Deploy کردن Metro Witness
اگر Dependencyهای موردنیاز از قبل فراهم باشند، Witness را میتوان مستقیماً با RPM نصب کرد. در غیر این صورت Package Managerهایی مانند yum یا zypper میتوانند Dependencyها را بهصورت خودکار نصب کنند.
sudo rpm -i <rpm_file>Witness در HCI Deploymentهای PowerStore پشتیبانی نمیشود.
پیکربندی Witness در PowerStore Manager
فقط Administrator، Security Administrator و Storage Administrator اجازه پیکربندی Witness را دارند. برای هر Cluster فقط یک Witness قابل تعریف است و همان Witness برای تمام Metro Sessionها استفاده میشود.
وضعیت Witness زمانی Engaged میشود که روی هر دو Local و Remote PowerStore System پیکربندی شده باشد.
sles15:~ # ls /opt/dell-witness-service/scripts- در PowerStore Manager مسیر Protection > Witness را باز کنید.
- در پنجره Metro Witness گزینه Add را انتخاب کنید.
- Name، IP Address/FQDN و Security Token را وارد کنید. Description اختیاری است.
- برای تولید Security Token از اسکریپت generate_token.sh استفاده کنید.
- گزینه Add را انتخاب کنید.
- Certificate Thumbprint مربوط به Witness را بررسی کرده و Confirm کنید.
Token پس از 10 دقیقه Expire میشود و مراحل افزودن Witness باید روی هر دو Local و Remote PowerStore System انجام شوند.
پس از ایجاد Witness، Metro Volumeها و Volume Groupهای موجود بهصورت خودکار به آن اختصاص پیدا میکنند. Resourceهای Metro جدید نیز بهصورت خودکار به همان Witness اختصاص داده خواهند شد.
ویرایش، جایگزینی و تغییر Host مربوط به Witness
در Witness Properties میتوان Name و Description را تغییر داد. برای تغییر IP Address یا FQDN باید Witness حذف و دوباره نصب شود.
برای جایگزینی Witness نیز ابتدا باید آن را از هر دو سیستم PowerStore حذف و سپس مجدداً اضافه کرد؛ زیرا Witness جدید Certificate متفاوتی دارد.
مانیتور کردن Metro Witness
در مسیر Protection > Metro Witness > [witness] میتوان Witness Properties را مشاهده کرد. Witness با تمام Nodeهای Applianceهای Cluster ارتباط دارد و Properties وضعیت Connection هر Node و Overall Connection State را نمایش میدهد.
- Initializing
- OK
- Deleting
- Partially Connected
- Disconnected
هر Metro Session نیز Witness State مستقلی دارد که میتواند شامل Initializing، Disengaged، Engaged، Disengaged Invalid Configuration or Unavailable، Disengaged Failed to Initialize و Unconfigure in Progress باشد.
حذف Witness
Witness را میتوان بدون توجه به وجود Metro Sessionهای اختصاصیافته حذف کرد. پس از حذف، Metro Sessionها برای تعیین رفتار هنگام Failure دوباره از Preference Ruleها استفاده میکنند.
رفتار Witness در Failure
اگر Connection میان Local و Remote System قطع شود، Metro Session وارد Fractured میشود و هر دو سیستم از Witness درخواست Fracture میکنند. Witness به اولین Request پاسخ Success و به Request دوم پاسخ Error میدهد.
سیستمی که Success دریافت کرده است Host I/O Access را حفظ میکند و سیستم دیگر خود را Demote میکند. اگر Preferred Up باشد معمولاً در اولویت قرار میگیرد؛ اگر Preferred Down باشد، Nonpreferred میتواند پاسخ Success دریافت کند.
پیکربندی Metro Volume
با فعال کردن Metro Configuration روی یک Volume، Host میتواند آن Volume را از طریق دو PowerStore متصل به یکدیگر مشاهده کند.
Volumeهای زیر قابل پیکربندی بهعنوان Metro نیستند:
- Volume Clone
- Volume دارای Protection Policy شامل Replication Rule
- Volume عضو Volume Group
- Volume دارای Read-Only Protection Policy
- Volume در حال Migration یا Import
- Read-Only Replication Destination باقیمانده پس از حذف Replication
- Storage > Volume را باز کرده و Volume را انتخاب کنید.
- Protect > Configure Metro Volume را انتخاب کنید.
- Remote System موجود را انتخاب یا Remote System جدید پیکربندی کنید.
- در صورت نیاز Placement مربوط به Volume را مشخص کنید.
- Configure را انتخاب کنید.
- در Remote System، Metro Volume را به Host Map کنید.
پیکربندی Metro Volume Group
Metro Configuration برای Volume Group نیز باعث میشود Host آن را از طریق دو PowerStore مشاهده کند. تمام Volumeهای داخل Volume Group بهعنوان یک Instance واحد در نظر گرفته میشوند و هر Action به همه اعضا اعمال میشود.
موارد زیر قابل پیکربندی بهعنوان Metro Volume Group نیستند:
- Volume Group خالی
- Volume Group Clone
- Volume Group بدون Write-Order Consistency
- Volume Group شامل Volumeهای غیرLocal
- Volume Group دارای Protection Policy با Replication Rule
- Volume Group دارای Read-Only Protection Policy
- Volume Group در حال Migration یا Import
- Volume Group از نوع Read-Only Replication Destination
- Storage > Volume Group را باز کنید.
- Volume Group را انتخاب و Protect > Configure Metro Volume Group را اجرا کنید.
- Remote System را انتخاب یا Remote System جدید پیکربندی کنید.
- Configure را انتخاب کنید.
- Metro Volume Group روی Remote System را به Host Map کنید.
تنظیم Metro Role
سیستمی که Metro Resource از آن پیکربندی شده است بهصورت خودکار Preferred تعیین میشود. اگر Resource در Fractured یا Paused باشد و Metro Witness وجود نداشته باشد، Preferred System Production Access و Association فعال Protection Policy را حفظ میکند.
در وضعیت Operating Normally یا Active/Active میتوان Role را بین Preferred و Nonpreferred تغییر داد.
Modify Preferred Role
برای تغییر Current Role یک Metro Resource انتخابشده استفاده میشود.
Set Local Role to Preferred
برای تبدیل چند Metro Resource از Nonpreferred به Preferred استفاده میشود و پیش از Planned Maintenance سیستم Preferred کاربرد دارد.
مانیتور کردن Metro Resourceها
برای مشاهده تمام Metro Resourceها از Dashboard مسیر Protection > Metro را باز کنید. انتخاب Checkbox هر Resource، Actionهای قابل اجرا روی آن را نمایش میدهد.
با انتخاب Metro Status نیز Metro Resource Details قابل مشاهده است. اطلاعات Metro را میتوان از Storage > Volumes یا Storage > Volume Groups و Card مربوط به Protection نیز بررسی کرد.
عملیات مدیریتی روی Metro Resource
Pause کردن Metro Resource
Pause زمانی استفاده میشود که Configuration Change در Operating Normally قابل انجام نباشد، سیستم Preferred یا Nonpreferred به Maintenance نیاز داشته باشد یا Failure روی Preferred رخ داده و Controlled Recovery به Promote کردن Nonpreferred نیاز داشته باشد.
با Pause شدن Metro Resource، Synchronization بهطور موقت متوقف میشود اما Production Access و Protection Policy روی Preferred فعال باقی میمانند.
- Protection > Metro را باز کنید.
- Metro Resource را انتخاب و Pause را اجرا کنید.
- عملیات را در Pause Metro Volume/Volume Group تأیید کنید.
Resume کردن Metro Resource
Resume را میتوان از Preferred یا Nonpreferred آغاز کرد. اگر Preferred Resource در Paused باشد، Synchronization با Nonpreferred دوباره آغاز و پس از تکمیل، وضعیت Active/Active برقرار میشود.
اگر Resource قبلاً Nonpreferred بوده و در وضعیت Promoted و Paused باشد، وارد Reprotecting میشود تا Synchronization با Preferred تکمیل شود.
اگر Resource مدت زیادی Paused بوده باشد، Data Accumulation میتواند مدت Synchronization را افزایش دهد.
Promote کردن Metro Resource
Promote برای Metro Volume مستقل یا Metro Volume Group در وضعیت Fractured یا Paused مجاز است.
اگر Preferred Fail شود، Metro Resource وارد Fractured میشود و برای فعال کردن Host و Production Access باید Resource روی Nonpreferred Promote شود.
اگر وضعیت Preferred System از سمت Nonpreferred قابل تشخیص نباشد، Promote ممکن است باعث شود هر دو سیستم I/O ارائه کنند در حالی که Synchronize نیستند. در صورت امکان Down بودن Remote System را پیش از Promote تأیید کنید.
پیش از Promotion از Metro Resource یک Snapshot گرفته میشود.
Demote کردن Metro Resource
اگر Storage Space سیستم Preferred تمام شود، Synchronization متوقف و Resource وارد Fractured میشود. برای اینکه Resource سمت Nonpreferred بتواند Promote شود، ابتدا Resource سمت Preferred باید Demote شود.
پایان دادن به Metro Resource
End کردن Metro Configuration باعث ایجاد دو Volume یا Volume Group مستقل میشود. اگر Remote Resource نگهداری شود، Protection Policy آن حذف، Hostها Unmap و SCSI WWN جدیدی به Resource اختصاص داده میشود.
- End Metro و نگهداری Resourceها روی Local و Remote System
- End Metro و حذف Remote Resource بههمراه Snapshotهای مرتبط
Remote Volumeها و Volume Groupهای مرتبط با Secure Snapshotهای Expireنشده قابل حذف نیستند.
جدول Actionهای مجاز روی Metro Resource
| Location | Metro Status | Modify Role | Promote | Demote | Pause | Resume | End Metro |
|---|---|---|---|---|---|---|---|
| Preferred | Operating Normally | بله | خیر | خیر | بله | خیر | بله |
| Preferred | Paused | خیر | خیر | بله | خیر | بله | بله |
| Preferred | Fractured | خیر | خیر | بله | بله | خیر | بله |
| Preferred | Switching to Metro Synchronization | خیر | خیر | خیر | بله | خیر | بله |
| Nonpreferred | Operating Normally | بله | خیر | خیر | بله | خیر | بله |
| Nonpreferred | Paused | خیر | بله، اگر سیستم دیگر Unreachable باشد | خیر | خیر | بله | بله |
| Nonpreferred | Fractured | خیر | بله، اگر سیستم دیگر Unreachable باشد | خیر | بله | خیر | بله |
| Nonpreferred | Switching to Metro Synchronization | خیر | خیر | خیر | بله | خیر | بله |
این جدول Use Caseهای معمول را پوشش میدهد و Failure Scenarioهای نادر را شامل نمیشود.
استفاده از Protection Policy همراه با Metro
اگر Protection Policy به Metro Resource موجود اختصاص داده شود یا Resource دارای Protection Policy به Metro تبدیل شود، Protection یکسان روی دو سیستم اعمال میشود.
Protection Policy ایجادشده روی Remote System از نوع Read-Only است و Read-Only Policy هر 15 دقیقه با تغییرات Synchronize میشود. User-Initiated Snapshot ایجادشده روی یک Storage System نیز روی سیستم مقابل ایجاد خواهد شد.
Synchronous و Asynchronous Replication همراه با Metro Resource پشتیبانی نمیشوند و Protection Policy شامل Replication Rule را نمیتوان به Metro Resource اختصاص داد.
برای آشنایی بیشتر با Snapshot و Clone در همین مجموعه، مقاله مدیریت Snapshot و Thin Clone در Dell PowerStore؛ قسمت سوم را میتوان بهعنوان بخش مکمل مطالعه کرد.
Protection Policy را میتوان روی Local یا Remote System و روی Preferred یا Nonpreferred اختصاص داد. Unassign باید روی Storage System انجام شود که Policy در آن اختصاص یافته است.
وقتی هیچ Metro Resource از Read-Only Protection Policy استفاده نکند، آن Policy بهصورت خودکار حذف میشود.
اگر Metro Resource در Fractured باشد یا Metro Session در Paused قرار داشته باشد، Snapshot فقط روی Active System ایجاد میشود. این Snapshotها پس از Self-Heal یا Resume به Remote System کپی نمیشوند و تا Expire یا حذف شدن روی Local System باقی میمانند.
استفاده از QoS همراه با Metro
اگر Metro Volume یا Volume Group دارای QoS Policy باشد، QoS Policy به Remote System Replicate نمیشود.
برای Metro Configuration دارای QoS توصیه شده است Policy یکسانی روی هر دو سمت Metro Resource پیکربندی شود.
اگر QoS فقط روی یک سمت وجود داشته باشد، Host ممکن است برای ارسال I/O بعضی Pathها را ترجیح دهد. همین وضعیت زمانی ممکن است رخ دهد که QoS روی هر دو سمت وجود داشته باشد اما QoS Limitها یکسان نباشند.
مطالب و محصولات مرتبط
- محصولات PowerStore
- حفاظت از داده در Dell PowerStore؛ قسمت اول
- پیکربندی Remote System برای حفاظت از داده در Dell PowerStore؛ قسمت دوم
- مدیریت Snapshot و Thin Clone در Dell PowerStore؛ قسمت سوم
جمعبندی مدیریت Metro Protection
Metro Protection در PowerStore به پیکربندی یک Resource محدود نمیشود. Remote System، مسیرهای Host، Preferred Role، Witness و وضعیت Metro Resource همگی در رفتار سیستم هنگام عملیات عادی، Maintenance و Failure نقش دارند.
پس از راهاندازی نیز شناخت Pause، Resume، Promote، Demote و End Metro ضروری است؛ زیرا مجاز بودن هر Action به وضعیت Resource و سیستمی که عملیات از آن آغاز میشود وابسته است. Protection Policy روی دو سمت Metro هماهنگ میشود، اما Replication Rule روی Metro Resource پشتیبانی نمیشود و QoS نیز باید بهصورت مستقل و ترجیحاً یکسان روی دو سمت تنظیم شود.
سوالات متداول
آیا Metro Protection برای تمام Resourceهای PowerStore قابل استفاده است؟
خیر. در محدوده این راهنما Metro Protection برای Volume و Volume Group ارائه میشود و بعضی انواع یا وضعیتهای Resource امکان تبدیل شدن به Metro را ندارند.
آیا Metro Witness برای هر Session جداگانه ساخته میشود؟
خیر. برای هر Cluster فقط 1 Witness قابل پیکربندی است و همان Witness برای تمام Metro Sessionها استفاده میشود.
Metro Witness از چه نسخهای در دسترس است؟
امکان افزودن Witness Server به Metro Protection از PowerStoreOS 3.6 و نسخههای بعدی در این راهنما ذکر شده است.
آیا Metro Resource میتواند Replication Rule داشته باشد؟
خیر. Synchronous و Asynchronous Replication همراه Metro Resource پشتیبانی نمیشوند و Protection Policy شامل Replication Rule قابل اختصاص به Metro Resource نیست.
Promote کردن Metro Resource چه زمانی امکانپذیر است؟
Metro Resource در وضعیت Fractured یا Paused میتواند Promote شود.
آیا QoS Policy به سمت Remote Metro Replicate میشود؟
خیر. QoS Policy روی Remote System Replicate نمیشود و توصیه شده است QoS یکسان روی هر دو سمت Metro Resource پیکربندی شود.
پس از Resume کردن Resource چه اتفاقی میافتد؟
Synchronization دوباره آغاز میشود و پس از تکمیل آن، Resource میتواند دوباره به وضعیت Active/Active بازگردد.
قسمت بعدی این مجموعه به مدیریت Remote Backup در Dell PowerStore اختصاص دارد. برای طراحی Metro Protection، بررسی Remote System، Host Connectivity یا ارزیابی Configuration موجود PowerStore میتوانید از خدمات تخصصی ذخیرهسازی آکو استفاده کنید.