مدیریت Replication در Dell PowerStore؛ قسمت پنجم

مدیریت Replication در Dell PowerStore؛ راهنمای Failover و Disaster Recovery | قسمت پنجم

مدیریت Replication در Dell PowerStore مجموعه‌ای از عملیات مرتبط با تکثیر Data میان Source و Destination، کنترل Replication Session و آماده‌سازی زیرساخت برای Failover و Disaster Recovery را در بر می‌گیرد. PowerStore برای Resourceهای مختلف از Asynchronous و Synchronous Remote Replication پشتیبانی می‌کند و رفتار هر روش از نظر Synchronization، RPO و عملیات قابل اجرا متفاوت است.

این مقاله قسمت پنجم مجموعه حفاظت از داده در Dell PowerStore است. در قسمت قبل، ساخت و اختصاص Protection Policy و Replication Rule بررسی شد. در این بخش، رفتار Sessionهایی که از این Policyها ایجاد می‌شوند، عملیات Pause و Resume، انواع Failover، آزمون Disaster Recovery برای NAS Server و Replication مربوط به Virtual Volumeها بررسی می‌شود.

مسیر مطالعه این راهنما

Replication در Dell PowerStore چگونه مدیریت می‌شود؟

Replication در PowerStore بر پایه ارتباط میان Source System و Destination System و Replication Rule موجود در Protection Policy شکل می‌گیرد. با اختصاص Protection Policy دارای Replication Rule به Resource، یک Replication Session ایجاد می‌شود و از آن پس وضعیت انتقال Data و عملیات مرتبط با Session قابل مدیریت است.

پیش از ورود به Session Management، اتصال Remote System و شبکه Replication باید آماده باشد. جزئیات این لایه در پیکربندی Remote System برای حفاظت از داده در Dell PowerStore بررسی شده است.

دو روش اصلی Remote Replication در این بخش Asynchronous و Synchronous هستند. تفاوت آن‌ها فقط در زمان انتقال Data نیست؛ RPO، نحوه Synchronization، محدودیت‌های File و Block Replication و رفتار Session هنگام تغییر Resource نیز متفاوت است. برای مرور مفهومی تفاوت این فناوری با Snapshot و Clone می‌توان مقاله تفاوت Snapshot، Clone و Replication در استوریج‌ها را نیز مطالعه کرد.

Asynchronous Replication و Synchronization بر اساس RPO

در Asynchronous Replication، تغییرات Destination از جمله Content، Size و Membership در Interval مشخصی بر اساس RPO تعریف‌شده اعمال می‌شوند. در هر Synchronization، تغییراتی که از Cycle قبلی ایجاد شده‌اند به Destination منتقل می‌شوند.

PowerStore از Asynchronous Remote Replication برای Volume، Volume Group، NAS Server و Virtual Volume پشتیبانی می‌کند. برای Virtual Volume، Synchronization فقط برای Snapshotهای Read-Only پشتیبانی می‌شود.

برای فعال‌سازی این نوع Replication، Protection Policy دارای Asynchronous Replication Rule به Resource اختصاص داده می‌شود. با این کار یک Replication Session ساخته شده و در بخش Protection > Replication قابل مشاهده است.

Synchronization می‌تواند طبق Schedule به‌صورت Automatic یا به‌صورت Manual انجام شود. Snapshotها از Source به Destination Synchronize می‌شوند و Efficiency مربوط به Block Sharing حفظ می‌شود.

در زمان Synchronization نیز امکان Planned Failover از Source، Failover از Destination، Pause کردن Session از Source یا Destination و حذف Session از طریق حذف Protection Policy وجود دارد.

Asynchronous Replication برای Block

هنگام ایجاد Asynchronous Replication Session، یک Resource متناظر و Read-Only روی Destination ایجاد می‌شود. یک تعریف Read-Only از Protection Policy نیز در Destination وجود خواهد داشت تا در صورت Failover مورد استفاده قرار گیرد.

اگر در طول Session عضوی به Volume Group اضافه شود یا Size آن تغییر کند، تغییر بلافاصله در Destination ظاهر نمی‌شود. برای اعمال تغییر می‌توان Manual Synchronization اجرا کرد یا تا Synchronization بعدی مبتنی بر RPO منتظر ماند.

در Block Replication امکان تغییر Asynchronous Replication به Synchronous Replication با ویرایش Replication Rule موجود در Protection Policy وجود دارد.

Asynchronous Replication برای File

در File Replication، Protection Policy به NAS Server اختصاص پیدا می‌کند و به‌صورت پیش‌فرض تمام File Systemهای موجود روی NAS Server محافظت‌شده از Source به Destination Synchronize می‌شوند.

وجود Replication Session مانع اضافه یا حذف File System نمی‌شود. هر تغییری که در File Systemهای Session ایجاد شود در Cycle بعدی Asynchronous Synchronization به Destination منتقل خواهد شد.

Synchronous Replication و RPO برابر صفر

در Synchronous Replication هر Update روی Data سیستم Source هم‌زمان با وقوع آن به Destination Replicate می‌شود. در نتیجه RPO برابر صفر است و دو سیستم در حالت Synchronization نگه داشته می‌شوند.

این روش برای Volume، Volume Group، Thin Clone، Block Snapshot و NAS Server قابل استفاده است. با اختصاص Protection Policy دارای Synchronous Replication Rule، یک Replication Session ایجاد می‌شود و نوع آن در PowerStore Manager به‌عنوان Synchronous قابل مشاهده است.

در زمان ایجاد Session، Storage Resource به Destination Replicate می‌شود و پس از آن تنها Updateهای جدید به سیستم مقصد منتقل خواهند شد.

Session را می‌توان با Planned Failover یا Unplanned Failover جابه‌جا کرد. همچنین Unassign کردن Protection Policy باعث حذف Replication Session می‌شود. اگر Session در وضعیت Operating Normally باشد، Unassign کردن Policy فقط از Source System امکان‌پذیر است.

Source دارای نسخه Write/Read از Policy است و Destination یک Copy از نوع Read-Only دارد. فقط نسخه Write/Read قابل ویرایش یا حذف است. اگر سیستم دارنده نسخه Write/Read Down شود، Failover نقش سیستم‌ها را تغییر می‌دهد و مدیریت Policy از Destination جدید امکان‌پذیر می‌شود.

Synchronous Replication برای Block

هنگام ایجاد Session، یک Resource متناظر Read-Only و یک نسخه Read-Only از Protection Policy روی Destination ساخته می‌شود.

Snapshotهایی که قبل از ایجاد Session از Resource گرفته شده‌اند به Destination Synchronize می‌شوند. بعد از ایجاد Session نیز User Snapshotها تقریباً هم‌زمان روی Source و Destination و با Content یکسان ایجاد می‌شوند.

برای تغییر Parameterهایی مانند Size، Name یا Performance Policy باید Replication Session ابتدا Pause شود. امکان تغییر Synchronous Block Replication به Asynchronous نیز از طریق ویرایش Replication Rule وجود دارد.

در Intracluster Migration، وضعیت Session هنگام Cutover به Paused for Migration تغییر می‌کند و پس از تکمیل Migration به وضعیت قبلی بازمی‌گردد. Sessionهایی که قبلاً Paused بوده‌اند همچنان Paused باقی می‌مانند.

در NDU، Sessionهای Operating Normally فعال باقی می‌مانند و Sessionهای Paused وضعیت Paused for NDU می‌گیرند. در Cluster Reconfiguration نیز امکان تغییر Replication Network، Expand یا Scale Down کردن Cluster یا تغییر Location وجود دارد و پس از تکمیل Reconfiguration، Replication ادامه پیدا می‌کند.

اگر Volume مقصد به Host Map شود، PowerStore برای آن Node Affinity تنظیم می‌کند تا I/Oها به Node انتخاب‌شده هدایت شوند. این رفتار برای Load Balancing و جلوگیری از Latency مربوط به Replication استفاده می‌شود و Node Affinity را می‌توان با REST API به‌صورت Manual تنظیم کرد.

برای Volume Group، تمام Memberها باید روی یک Appliance باشند و فقط Volume Groupهایی که Write-Order Consistency برای آن‌ها پیکربندی شده است می‌توانند Protection Policy دارای Synchronous Replication Rule دریافت کنند.

Policy اختصاص‌یافته به Volume Group روی تمام Memberها اعمال می‌شود و Volumeهای منفرد داخل آن Group را نمی‌توان با Protection Policy جداگانه محافظت کرد. تغییر Parameterهایی مانند Name، Performance Policy و Write-Order Consistency نیز به Pause کردن Session نیاز دارد.

Synchronous Replication برای File

در File Replication نیز Protection Policy روی NAS Server قرار می‌گیرد و File Systemهای موجود روی Server به Destination Synchronize می‌شوند. در طول Session همچنان امکان اضافه یا حذف File System وجود دارد.

هنگام ایجاد Synchronous Replication Session، NAS Server و File Systemهای خالی روی Destination ایجاد می‌شوند و File Server Configuration و Read-Only Protection Policy نیز Replicate می‌شوند.

NAS Server مقصد بدون Active IP Configuration ساخته می‌شود و File Systemها نیز بدون Share فعال در دسترس هستند. File Systemهای موجود هنگام ایجاد Session به Destination منتقل می‌شوند و Updateهای بعدی نیز هم‌زمان با وقوع Replicate خواهند شد.

افزایش Size یک File System تحت Synchronous Replication ابتدا نیازمند Pause کردن Session است، اما کاهش Size چنین نیازی ندارد.

Pause و Resume کردن Replication Session

Pause و Resume ابزارهای اصلی برای کنترل موقت انتقال تغییرات میان Source و Destination هستند. کاربرد آن‌ها فقط توقف انتقال نیست؛ برخی تغییرات Resource و عملیات زیرساختی نیز به Session Paused نیاز دارند.

Pause کردن Replication Session

هنگام Pause کردن Session، تغییراتی که پس از آن روی Resource موجود در Source ایجاد می‌شوند به Destination Replicate نمی‌شوند. Pause را می‌توان از Source یا Destination انجام داد.

در Synchronous Replication، هنگام Pause یک Recovery Snapshot ایجاد می‌شود تا هنگام Resume به‌عنوان Last Common Base مورد استفاده قرار گیرد.

Resume کردن Replication Session

Resume باعث می‌شود تغییراتی که در زمان Pause روی Resource سیستم Source ایجاد شده‌اند با Destination Synchronize شوند.

در Synchronous Replication، Synchronization بر اساس Recovery Snapshot ایجادشده هنگام Pause انجام می‌شود. Host Data نوشته‌شده طی Pause نیز Synchronize می‌شود و سپس Replication مداوم دوباره برقرار خواهد شد.

Failover در Dell PowerStore

Failover نقش Source و Destination را جابه‌جا می‌کند و جهت Replication Session را معکوس می‌سازد. Planned Failover توسط User آغاز می‌شود و قبل از جابه‌جایی Source و Destination را Synchronize می‌کند، در حالی که Unplanned Failover در پاسخ به Failure سیستم Source و از Destination آغاز می‌شود.

در جریان Failover، I/O روی Source Object متوقف می‌شود. در Planned Failover، Source و Destination نیز Synchronize می‌شوند. سپس Session متوقف، Role سیستم‌ها جابه‌جا و جدیدترین Version مربوط به Object روی Source جدید Promote می‌شود. بعد از آن I/O روی Source جدید توسط User Resume می‌شود.

Test Failover

پس از راه‌اندازی Replication Session می‌توان Failover را به‌صورت آزمایشی اجرا کرد تا Configuration سایت‌ها و آمادگی آن‌ها برای Disaster Recovery بررسی شود.

در Test Failover، Destination با Replicated Data یا یک Point-in-Time Snapshot در اختیار Production Access قرار می‌گیرد. Destination Resource به حالت Write/Read می‌رود و Hostها و Applicationها می‌توانند به آن دسترسی پیدا کنند؛ در همین زمان Replication در Background ادامه خواهد داشت.

در پایان Test می‌توان Failover را به Test Data فعلی انجام داد و Data ایجادشده طی Test را حفظ کرد، یا Stop Test Failover را انتخاب کرد تا Destination دوباره با جدیدترین Data سیستم Source Synchronize شود. پیش از پایان Test نیز می‌توان از Test Data یک Snapshot ایجاد کرد.

در طول Test Failover روی Destination امکان تغییر Volume Group Membership، افزایش Volume Group Size، تغییر Volume Group Name، آغاز Migration یا حذف Protection Policy وجود ندارد. این Actionها از Source همچنان قابل اجرا هستند.

Planned Failover را نمی‌توان هنگام Test Failover آغاز کرد. برای اجرای آن باید ابتدا Test متوقف شود. Unplanned Failover در پاسخ به Disaster همچنان می‌تواند رخ دهد.

Session را در طول Test می‌توان Pause و Resume کرد. حذف Replication Session در این زمان باعث لغو Test می‌شود.

Planned Failover

Planned Failover یک انتقال کنترل‌شده از Source به Destination است. پیش از Failover، Destination با Source Synchronize می‌شود تا از Data Loss جلوگیری شود.

پیش از شروع، I/O مربوط به Applicationها و Hostها باید متوقف شود. Session در حال Planned Failover را نمی‌توان Pause کرد.

Planned Failover را می‌توان از Current Source Data یا یکی از Snapshotها آغاز کرد. این عملیات هم از Replication Session و هم از تب Protection مربوط به Resource قابل آغاز است.

برای Synchronous Replication، Planned Failover از Source و زمانی قابل آغاز است که Session در وضعیت Normally Operating باشد. به‌دلیل Synchronization کامل، Failover باعث Data Loss نمی‌شود؛ با این حال توقف I/Oهای Host و Application پیش از عملیات توصیه می‌شود.

پس از Planned Failover، Replication Session غیرفعال است. برای Synchronize کردن Destination Storage Resource و Resume کردن Session باید Reprotect اجرا شود.

Auto-Reprotect نیز می‌تواند پیش از Failover انتخاب شود. پس از تکمیل Synchronization، Replication در جهت معکوس در RPO بعدی شروع می‌شود و Source و Target به وضعیت Normal بازمی‌گردند.

Unplanned Failover

Unplanned Failover در پاسخ به Eventهای Source System مانند Failure سیستم یا رخدادهایی که Production Access را متوقف می‌کنند اجرا می‌شود.

این Failover از Destination آغاز می‌شود و Production Access به Destination Resource اصلی را با استفاده از Point-in-Time Snapshot فراهم می‌کند. هنگام شروع می‌توان جدیدترین Data Copy یا یکی از Snapshotهای موجود را به‌عنوان Source Data انتخاب کرد.

پس از برقراری مجدد Connection با Resource Source اصلی، Source System قبلی در Destination Mode قرار می‌گیرد. برای Synchronize کردن Storage Resource و Resume کردن Replication Session باید Reprotect اجرا شود.

ملاحظات Replication و Disaster Recovery برای NAS Server

در Block Replication، اگر Source برای NDU در حالت Pause باشد و Destination Up باشد، وضعیت Destination به Paused_System تغییر می‌کند. اگر Destination در طول NDU سیستم Source Down باشد، پس از Up شدن وضعیت آن OK باقی می‌ماند.

در File Replication، هنگامی که Source برای NDU Paused است، Destination بدون توجه به Connectivity در وضعیت OK باقی می‌ماند.

برای NAS Server چند روش برای آزمون Disaster Recovery وجود دارد: Clone کردن NAS Server با IPهای یکتا، Clone کردن NAS Server در Isolated Network با IPهای تکراری و Planned Failover.

Clone کردن NAS Server با IPهای یکتا

Clone کردن NAS Server روش توصیه‌شده برای DR Testing است، زیرا می‌توان یک نسخه مستقل ایجاد و بدون تأثیرگذاری بر Production آن را آزمایش کرد.

برای دسترسی به NAS Server جدید باید Network Interface جدید با IP Address یکتا پیکربندی شود. IP نباید روی Source یا Destination NAS Server دیگری در حال استفاده باشد. برای Join کردن Server به Active Directory نیز Configurationهای یکتا لازم است.

تغییرات ایجادشده روی Cloned File System و Production File System روی یکدیگر تأثیر ندارند و پس از تکمیل Test می‌توان Cloned Server را حذف کرد.

DRT در Isolated Network با IPهای تکراری

در برخی سناریوها لازم است Disaster Recovery با همان Network Configuration مربوط به Production آزمایش شود. استفاده از IPهای یکسان در شبکه Production باعث Conflict می‌شود؛ به همین دلیل Test باید در Environment جداشده انجام شود.

PowerStoreOS 3.6 و نسخه‌های بعدی امکان ساخت Isolated Disaster Recovery Testing Environment یا DRT را فراهم می‌کنند. این محیط اجازه می‌دهد NAS Server تحت Replication با همان IP Address و Hostname سیستم Production آزمایش شود، بدون اینکه Production تحت تأثیر قرار گیرد.

برای این معماری یک Isolated Network و DRT Router مستقل ایجاد می‌شود و Link Aggregation نیز روی Network I/O Portها مورد نیاز است. سپس با PSTCLI یا REST API یک Dedicated Networking Environment روی Destination System ساخته می‌شود.

NAS Server مربوط به DRT یک Full Copy از Production Environment است و در یک Test Environment جداشده اجرا می‌شود.

پیکربندی DRT با PSTCLI

در نمونه PSTCLI، ابتدا Name مربوط به NAS Server مقصد دریافت می‌شود.

[SVC:service@9CB0BD3-B user]$ pstcli -d <PowerStore_IP> nas_server show
# | id | name | operational_status | current_node_id | file_interfaces.ip_addre~
--+-------------+--------+--------------------+-------------------
1 |647f545a-4b11-5cdd-4d4c-eeeba81eb143 | File80| Started | R2C4-appliance-1-node~| 127.1.1.1

سپس NAS Server با Name جدید و Switch مربوط به DRT Clone می‌شود.

[SVC:service@9CB0BD3-B user]$ pstcli -d <PowerStore_IP> nas_server -name File80 clone -name File80_c -is_dr_test true
Success

در مرحله بعد IP Port ID مربوط به NAS File Bond متصل به Isolated Network دریافت می‌شود.

[SVC:service@9CB0BD3-B user]$ pstcli -d <PowerStore_IP> ip_port_show -output nvp
8: id =IP_PORT23
 current_usages =
 ip_pool_addresses =
 bond:
 name=BaseEnclosure-NodeA-bond1

File Interface برای Cloned NAS Server ایجاد می‌شود.

[SVC:service@9CB0BD3-B user]$ pstcli -d <PowerStore_IP> file_interface create -nas_server_name File80_c -ip_address "10.10.10.10" -prefix_length 24 -gateway "10.10.10.1" -vlan_id 5 -ip_port_id IP_PORT23
Created
# | id
--+-----------------------------------
1 |64830ae5-2760-59ce-4c90-82772509648e

در پایان File Interfaceها قابل مشاهده هستند.

[SVC:service@9CB0BD3-B user]$ pstcli -d <PowerStore_IP> file_interface_show
# |id | nas_server_id | ip_address | prefix_length | gateway | is_disabled
--+-------------+--------+--------------------+-------------------
1 |647f5509-11f4-a52d-ee1f-82772509648e | 647f545a-4b11-5cdd-4d4c-eeeba81eb143 | 10.10.10.10 |24 | 10.10.10.1 | no
2 |64830ae5-2760-59ce-4c90-82772509648e | 6483092f-3e71-8a92-0a0b-82772509648e | 10.10.10.10 |24 | 10.10.10.1 | no

پیکربندی DRT با REST API

در صورت استفاده از REST API، NAS Server با Endpoint مربوط به clone در Namespace مشخص Clone می‌شود و مقدار is_dr_test روی true قرار می‌گیرد.

سپس Endpoint مربوط به File Interface اجرا می‌شود و Private Network Parameterها در اختیار آن قرار می‌گیرند. File Interface مربوط به Cloned NAS Server با همان IP Address، Netmask و Gateway سیستم Production ایجاد می‌شود و باید از Bond Interface یا IP Port مرتبط با Private Network استفاده کند.

نتیجه، NAS Serverای در وضعیت Up است که می‌تواند برای DRT در Isolated Network استفاده شود.

Replication برای vVol و VMware SRM

PowerStore با VMware Site Recovery Manager یا SRM یکپارچه می‌شود تا Asynchronous Replication برای Virtual Volumeها پشتیبانی شود.

Remote Protection ماشین مجازی با استفاده از vSphere Storage Policy-Based Management یا SPBM پیکربندی می‌شود و SRM نیز Recovery ماشین مجازی را پس از Failure مدیریت می‌کند.

Snapshot Rule و Replication Ruleهایی که در PowerStore ایجاد شده‌اند در vSphere در دسترس قرار می‌گیرند و می‌توان آن‌ها را به Storage Policy اضافه کرد.

Replication Group شامل Virtual Volumeهایی است که باید با یکدیگر Replicate شوند و به‌عنوان واحد Replication و Failover پیکربندی‌شده در vSphere عمل می‌کند.

برای vVol می‌توان Snapshotهای Read-Only و Write/Read ساخت، اما Manual یا Scheduled Synchronization فقط روی Snapshotهای Read-Only اعمال می‌شود.

برای بررسی تکمیلی Recovery در VMware می‌توان مقاله VMware Site Recovery Manager و زیرساخت Disaster Recovery را مطالعه کرد.

پیش‌نیازهای vVol Replication

Local و Remote System باید Connected باشند و Capability مربوط به vVol را داشته باشند. Storage Containerها نیز باید روی هر دو سیستم تعریف شوند تا Pairing امکان‌پذیر باشد.

اگر هر سیستم فقط یک Storage Container داشته باشد، Pairing خودکار انجام می‌شود. در غیر این صورت Destination مربوط به Storage Container باید به‌صورت Manual مشخص شود.

ایجاد Virtual Volume Replication Session

یک Copy از نوع Read-Only از Protection Policy با همان Name به PowerStore اضافه می‌شود و با Lock Icon قابل شناسایی است.

پس از ارتباط VM با Replication Group، Replication Group و Replication Session به‌صورت خودکار در PowerStore ایجاد می‌شوند.

مانیتورینگ Replication Group

هنگامی که Storage Policy دارای PowerStore Replication Rule در VMware به یک vVol-based VM اختصاص داده می‌شود، PowerStore برای vVolهای موجود در همان Resource Group یک Replication Session ایجاد می‌کند. VMware SRM از این Resource Groupها برای مدیریت VMهای محافظت‌شده در Replication Group استفاده می‌کند.

Timeline مربوط به Data نمایش‌داده‌شده نیز قابل تنظیم است.

Recovery ماشین مجازی

VMware SRM یا Site Recovery Manager عملیات Disaster Recovery ماشین‌های مجازی را در Failure State خودکار می‌کند.

برای فعال‌سازی Recovery باید Recovery Plan در SRM پیکربندی شود. Recovery Plan مجموعه‌ای از Stepهای از پیش تعریف‌شده را روی Replication Groupهای انتخاب‌شده اجرا می‌کند و عملیات Failover، Reprotect و Test Failover را شامل می‌شود.

در vSphere یک Protection Group شامل یک یا چند Replication Group و Recovery Plan ایجاد می‌شود. هنگام Failure، SRM Recovery Plan را روی Virtual Volumeهای موجود در Replication Group اجرا می‌کند و وضعیت Replication Session در طول Recovery از PowerStore قابل مانیتور است.

مطالب و محصولات مرتبط

جمع‌بندی مدیریت Replication

مدیریت Replication در Dell PowerStore از انتخاب Asynchronous یا Synchronous Replication فراتر می‌رود. رفتار Synchronization، نحوه Pause و Resume، وضعیت Snapshotها، محدودیت‌های Block و File، Failover و Reprotect همگی بخشی از چرخه عملیاتی Replication Session هستند.

برای سناریوهای Disaster Recovery، Test Failover امکان بررسی مقصد بدون توقف Replication Background را فراهم می‌کند و NAS Server نیز می‌تواند با Clone مستقل یا DRT در Isolated Network آزمایش شود. در محیط VMware، vVol Replication از طریق Storage Policy و Replication Group با vSphere و SRM یکپارچه می‌شود.

ادامه این مجموعه در قسمت ششم به Metro Protection، Metro Witness و مدیریت Metro Resource اختصاص دارد.

سوالات متداول