EMC RecoverPoint – Repository and Journal Volume

در پست های قبل بیشتر از زاویه Hardware به RecoverPoint  پرداخته ایم. در این پست میخواهیم بیشتر به موضوعات نرم افزاری آن بپردازیم. همان طور که می دانید، RPA تمام جنبه های Data Protection برای یک storage group  را مدیریت می کند. مانند نگهداری image  ها در Journal Volume. اما Journal Volume  چیست؟ Repository Volume به چه معناست؟
در ادامه به توضیح این دو مفهوم می پردازیم:
Repository Volume

Repository Volume  یک نوع خاصی از  Volume است که بر روی SAN برای هر RPA Cluster  مشخص می شود. نکته ی مهمی که لازم است به یاد داشته باشید. یک Repository volume برای هر RPA Cluster باید وجود داشته باشد.  این Volume  اطلاعات Configuration  در مورد RPA  و Consistency Group  را نگهداری می کند. این حافظه برای مثال در هنگامی که  یکی از RPA  ها در یک کلاستر fail  بشود و مابقی RPA  ها در همان کلاستر جای آن را میخواهند پر کنند، استفاده می شود. در کنار این عملکرد،  Repository Volume  یک volume  معمولی محسوب می شود. اگرچه، LUN مورد استفاده نباید از نوع  Thin  باشد و ترجیح بر این است که از نوع Thick  و یا traditional RAID LUN  باشد.  به علاوه Volume  نمی تواند در برروی  VPLEX  قرار داشته باشد.

 

Journal Volumes

Journal Volume به مفهوم Consistency Group  مربوط است. که پیشتر در مورد آن توضیح داده ایم.  در حال حاضر Consistency Group را می توان به صورت گروهی از Volume  ها در نظر گرفت. Consistency Group  این تضمین را می دهد که تغییرات Production Volume حتما در volume  کپی به همان صورت که ترتیب نوشتن آن در سمت اول بوده است قرار میگیرد.

در نتیجه، کپی ها همواره معتبر هستند. حال به Journal Volumes بر میگردیم. هر کپی از داده در Consistency Group  باید حداقل یک volume  که به ثبت زمان کپی گرفتن داده یا نقطه ای که از آن کپی گرفته شده می پردازد را دارا باشد. این کار را Journal انجام می دهد. Journal  از داده snapshot  میگیرد تا داده replicate  شود. این مقدار تا جایی که فضایی برای ذخیره سازی باشد اطلاعات را ذخیره می کند. دو نوع Journal Volume وجود دارد:

  • Replica ( Copy ) Journal
  • Production Journal ، این فضا در هنگام عملیات های معمول استفاده نمی شود. مگر در هنگامی که ارتباط سایت ها جابه جا شود و سایت دوم به عنوان سایت اول و سایت اول به عنوان سایت دوم مشخص شود، از این Journal استفاده می شود.

Journal Volume نمی تواند به هیچ هاستی ارائه شود و تنها RPA  های در کلاستر می توانند به آن دسترسی داشته باشند.

در Replication  به صورت  Sync هر نوشتن در Replica Journal  نگهداری می شود. بنابراین میتوانید به هرتقطه از زمان آن را بر گردانید. در Replication  به صورت Async  چندین نوشتن به عنوان یک گروه در یک Snapshot  قرار میگیرند.  مقدار  Replication  برای Async  میتواند هم به صورت ثانیه و هم به  MB باشد.

 

RecoverPoint Consistency Group

در بالا شما مثالی از Continuous Remote Replication – CRR  و Continuous Data Protection – CDP را می بینید. همان طور که مشاهده می کنید. در اینجا ما ۳ عدد Journal Volume  داریم.

۲ Replica journal

۱ production volume

همان طور که قبل تر هم بیان کردم، در عملیات معمولی  production Journal  شرکت نمی کند و CDP  و Replica Volume  به همراه  CRR Replica برای ازتباط بین RPA  ها استفاده می شوند.

 

EMC RecoverPoint – Consistency Groups and Replication sets

برای درک بهتر RecoverPoint دو مفهوم Consistency Group  و  Replication set را باید به صورت گسترده تری بررسی کرد.

اگر میخواهید از داده ای محافظت کنید، در Recover Point  باید از Consistency Group  استفاده کنید. Consistency Group  به شما این اطمینان خاطر را می دهد که هر آنچه در Protection Volume  نوشته می شود یک کپی از آن هم به ترتیب صحیح و به صورت Consistent  نوشته می شود. بنابراین نسخه کپی شده میتواند همواره به جای نسخه اصلی استفاده شود.  حال اگر بخواهید از یک Volume  تنها به صورت Local  محافظت کنید چه؟
در ساده ترین مثال، در این موقعیت باید یک Consistency Group با یک Protection volume  و یک  Secondary volume ساخته شود، ولی ممکن است در برخی موارد یک Data set به یک Data set مربوط باشد. مثل Database data  و Database log. برای این مثال نیز Consistency Group یک راهکار بسیار مناسب است به این دلیل که database_data_volume  و database_log_volume هردو هم در Production  و هم در Replicated  سایت در حالت Consistent  هستند.

 

RecoverPoint copies

تمامی Volume   هایی که دارای یکی از شرایط زیر باشند در یک Consistency Group  هستند:

یک source  برای replication به نام Production copy

یک Target به نام Local Copy یا Remote copy

RecoverPoint Copies

همان طور که در تصویر بالا مشاهده میکنید، هر کپی journal  مخصوص به خود را دارد.

 

یک سری محدودیتی در این قسمت وجود دارد:
یک Production copy  می تواند تا ماکزیمم ۴ تا non-production  کپی به ازای Consistency Group  داشته باشد.

در Local production محدودیت یک Production copy برای یک  Local copy  وجود دارد.

در Remote Replication  یک Production copy  تا ۴ Non-production (تنها در صورتی که یک local copy  وجود نداشته باشد.)، اگر Local copy  وجود داشته باشد تا ۳ عدد Remote copy  می توانند باهم در یک Consistency Group  قرار داشته باشند.

برای RecoverPoint/SE  محدودیت یک Production  و  یک  Copy وجود دارد.

در تصویر زیر به یک Consistency Group  با یک Production Group،  یک  Local Copyو یک Remote copy  توجه کنید.

RecoverPoint Consistency Group

 

Replication sets

Consistency Group  از یک یا چند تا Replication set  ساخته می شود. هر Replication set  از Production volume  به اضافه  هر Local  و یا Remote copy volume که Replicate  می کند تشکیل می شود. تعداد Replication set  در سیستم Recoverpoint  مناسب با تعداد Production volume  هایی است که در حال Replicate  هستند. در تصویر بالا، ما در واقع یک  Replication set  داریم زیرا تنها یک Production volume  وجود دارد. بر اساس محدودیت ها همان طور که در قبل بیان شده است میتوان تا ماکزیمم ۵ عدد Volume  برای یک  Replication set متصور شد. یک Production volume  و  ۴ عدد Copy volume. در تصویر بالا یک Replication set  از یک Production volume  ، یک Local copy  و یک Remote  کپی وجود دارد.

RecoverPoint Protection

یک خلاصه کوتاه: به طور ساده RecoverPoint Protection  را می توان به صورت زیر تعریف کرد:

  1. تعریف Production volume
  2. تعریف Copy volume
  3. تعریف Journal volume
  4. ایجاد حداقل یک Consistency Group با تعداد مناسب Replication set  برابر با  Production volume

در واقع این مراحل تنها یک دید کلی از این موضوع است.  برای برقراری این مفاهیم یک ارتباط منطقی بین Production  و Replication copies  هم لازم داریم.

معماری EMC RecoverPoint

برای اینکه متوجه شویم RecoverPoint  دقیقا چطور کار میکند باید تمام اجزای آن را بشناسیم. معماری RecoverPoint  شامل چندین جز از جمله نرم افزار RecoverPoint Appliance،  Write splitter و … می باشد. در این پست به معرفی این اجزا به صورت خلاصه می پردازیم.

(RecoverPoint Appliance (RPA

EMC RecoverPoint  به صورت Appliance-based  است. که این راه حل را بسیار انعطاف پذیر میکند. RPA  می تواند به صورت فیزیکی  physical appliance و Virtual RPA  باشد.

 

Physical RPAتصویر شماره یک: یک RPA فیزیکی

RecoverPoint RPA میتواند Data protection  و  Replication  را مدیریت کند.

vRPA

Virtual RPA  به طور کامل یک مدل نرم افزاری است و سرویس های بر روی Platform ESX را بهینه سازی می کند.

RPA

(RPA (RecoverPoint Appliance  دارای interface های  Fibre Channel،  WAN و  LAN مشخصی است.

  • Fiber Channel برای تبادل اطلاعات با Local host applicatin  و Storage subsystem  ها است.
  • WAN  برای فرستادن داده به یک RPA  دیگر استفاده می شود.
  • Management  برای مدیریت سیستم Recoverpoint استفاده می شود.

 

Array Based Writer Splitter

RecoverPoint Write Splitter  برای Split  و یا  Duplicate کردن در حین نوشتن به کار می رود.  اولین دستور نوشتن ابتدا به RecoverPoint appliance  فرستاده می شود و سپس یک duplicate  به سمت Primary Storage  ارسال می شود. نکته ی مهم این است که متوجه باشیم Write splitter  ماهیتی Array base  است. به این معنا که لازم نیست به طور واقعی  Recoverpoint appliance  بین Host  و  Storage array متصل کنید. به جای آن host به طور مستقیم با Storage Array  ارتباط برقرار می کند(حتی نه به عنوان جزئی از  RecoverPoint .(Write Splitter  در حال حاضر به طور build-in بر روی EMC VNX, VMAX, VPLEX  وجود دارد.

 

ReocverPoint Cluster

یک کلاستر باید شامل یک یا بیشتر RPA  فعال در یک سایت RecoverPoint باشد. این موضوع باعث High Availability  می شود به این مفهوم که اگر یکی از RPA ها در کلاستر fail  بشود، RecoverPoint  به سرعت به مابقی RPA  ها در کلاستر سوئیچ می کند. کلاستر RecoverPoint یک ماهیت منطقی را داراست. گروهی از ۲ تا ۸ RPA به صورت فیزیکی و یا مجازی که باهم کار می کنند تا کار Replication و  data protection  را انجام بدهند. نکته مهم این است که: تعداد RPA  ها در یک RPA باید در تمامی RPA کلاستر ها یکسان باشد.

 

RecoverPoint System

یک سیستم RecoverPoint  یک ماهیت مستقل منطقی است که داده ها بین سایت ها با یک نصب RecoverPoint می توانند Replicate  و Protect  کنند.

شما می توانید تمام RPA ها را از طریق یکAddress   IP مدیریت کنید. RecoverPoint  می تواند تا ۵ عدد کلاستر بهم متصل را از طریق یک کنسول مدیریتی مدیریت کند. البته ماکزیمم تعداد کلاسترها برای لایسنس ReocerPoint/EX  و  RecoverPoint/CL تعداد ۵ می باشد و برای RecoverPoint/CL تعداد ۲ کلاستر می باشد.

 

تصویر شماره دو: یک سیستم RecoverPoint  که شامل ۳ کلاستر است.

 

تعداد کلاستر های مورد نیاز بسته به نیاز و نحوه ی استفاده RecoverPoint  به صورت  Remote  یا Local  و یا هر دو می تواند متفاوت باشد.

EMC RecoverPoint – Snapshots and Bookmarks

در پست امروز میخواهیم که در مورد محصول EMC ReocverPoint  بیشتر توضیح بدهیم. ابتدا با توضیحی ساده در مورد  Data protection  و  Data availability   که اساس این مفهوم است به طور کلی شروع می کنیم.

Data Protection  و  Availability

قطعا نیازی نیست تا از اهمیت Availability و  Data Protection  صحبت کرد. تنها تصور کنید که چه اتفاقی خواهد افتاد اگر شما در محیط تان داده ای را از دست بدهید. و چه راه هایی وجود دارد برای اینکه از این از دست دادن اطلاعات جلوگیری کنیم. در مورد خطای انسانی چه کاری می توان کرد؟ آیا از دست دادن اطلاعات تنها نگرانی موجود است؟ قاعدتا این موضوع با back up  گرفتن به صورت هفته ای هم حل نمی شود. از طرف دیگر، مشکلات مالی سر راه هم وجود دارد. همچنین بیشتر راه حل های Data protection  و  availability  هزینه های گزافی دارند. پس چه راه حلی وجود دارد؟

در مورد RecoverPoint

EMC RecoverPoint  به طور خلاصه یک راه حل در سطح بلاک است که می تواند Replication  را به صورت Local  و Remote  انجام دهد. در نتیجه این امکان را به وجود می آورد که:
Local data protection  برای نیاز های عملیاتی و نیاز بازیابی Application ها استفاده می شود. با استفاده از (Continous Data Protection (CDP به طور دائمی اطلاعات را دریافت و تغییرات را ذخیره می کند و Point-in-time recovery (بازگشت در یک نقطه خاص) را بدون از دست رفتن اطلاعات فعال  می کند.

Remote Data Protection  برای دلایل  Disaster Recovery استفاده می شود. (Continous remote replication (CRR پشتیبانی Sync  و  A-sync  برای replication  بین سایت های remote  که به صورت  FC  و WAN می باشند را فراهم می کند. با RecoverPoint A-sync replication  میتوان crash- consistent protection  و   بازگشت به به یک نقطه مشخص را فراهم کرد. (با RPO  بسیار کوچک) و با Sync replication  از طریق FC  می توان به Zero RPO رسید.

مخلوطی از دو مورد بالا

(Concurrent local and remote replication ( CLR محافظت و بازگشت داده از یک سایت و همچنین در یک سایت به صورت remote را فراهم می کند.

 

 

RecoverPoint Replication options

 

به جز مواردی که در بالا بیان شد،  RecoverPoint  می تواند  با Replicate کردن داده برای هدف های تست محیط های isolated  و  اهداف development  استفاده شود. اگر در محیط تان VPLEX  دارید حتی می توانید از  Storage Array های برند دیگر هم استفاده کنید. برای محافظت داده ها از Error  و Attack  با استفاده از CDP  می توانید با استفاده از تصویر قبلی، آن را به وضعیت قبلی که در حالت سالم بوده است برگردانید.

RecoverPoint System

RecoverPoint  یک سیستم کاملا پیچیده است و شامل چندین قسمت می شود. جزئیات بیشتر آن در قسمت های بعدی بیشتر توضیح داده شده اند.

ساده سازی سرویس های نرم افزاری App Owners و Backup Admins

مدیران سرویسهای نرم افزاری (App Owners  ) و مدیران تولید نسخ پشتیبان ( Backup Admins ) می توانند دیتا سنترها و زندگی خود را ساده تر نمایند.

زمانی که مدیران سرویسهای نرم افزاری (App Owners  ) و مدیران تولید نسخ پشتیبان ( Backup Admins ) دچار تناقض در درک اولویتها می گردند، نگهداری دیتا سنتر با راندمان بالا میسر نخواهد بود. محدودیتها تکنیکی در گذشته، تولید کنندگان و مدیران سرویسهای نرم افزاری را مجبور می کرد که به Backup Admin برای تولید نسخ Backup و  Recoveryاز دیتابیسهای خود تکیه کنند. اگر روش مورد استفاده از سوی Backup Admin قادر به پوشش SLA درخواستی از سوی Application Owner نباشد، آنگاه Application Owner ها در پاسخ، خود به طور جداگانه اقدام به تولید نسخ پشتیبان مورد نیاز خود می کنند. این راهکار بدین معناست که دیتا سنترها در تمام دنیا به سیلوهای بزرگی برای نگهداری اطلاعات غیر ضروری و تکراری تبدیل شده اند که این موضوع خود تناقض در درک اولیتها از سوی Backup Admin ها و Application Owner ها را بیشتر نمایان می نماید.

در حالیکه Backup Admin، به همان شیوه سنتی خود در حال تهیه نسخ پشتیبان هستند، معمولا از تولید نسخ پشتیبان جداگانه و تکررای از سوی Application Owner مجموعه نیز کاملا غافل هستند. Application Owner  نیز تا زمانی که این نسخ پشتیبان اضافی که بروی دیسک ( فارغ از نوع آنها ) تولید می شود، در دسترس آنها باشد به بهره برداری از آن می پردازند. و چه بسا که فضای مورد استفاده از سوی Application Owner برای تولید این نسخ پشتیبان اضافی، بروی هارددیسکهایی با سرعت و قیمت بسیار بالایی باشد. در EMC ما به این ساختار هزینه بر و ناکارآمد، ” Accidental Architecture ” ( معماری تصادفی ) می گوییم.  و جالب است بدانید علیرغم آنچه شما فکر می کنید این ساختار در سازمانهای مختلف، بسیار رایج است. تنها اگر اولویت میان Application Owner و Backup Admin بر همدیگر منطبق شوند و دارای همزمانی شوند است که یک ساختار ایده آل و ساده تولید می گردد که می تواند تمامی نیازهای SLA مورد درخواست Application Owner را پاسخگو باشد.

EMC این معماری ایده آل را با راهکار Data Domain Boost for Enterprise فراهم نموده و امکان سادگی و امکان همزمانی الویتها را برای هر دو گروه Backup Admin و Application Owner تولید کرده است.

DD Boost for Enterprise Apps با تولید یکپارچگی توسط Client خود، سرور Basckup را بطور کامل دور می زند ( Bypass ) و سبب حذف تمامی ساختارهای تصادفی می گردد. این موضوع قابلیت کنترل مستقیم بکاپ های تولید شده از نرم افزارهای دلخواه Application Owner توسط Data Domain را برای آنها فراهم می کند. همچنین بعنوان یک متمم برای این قابلیت جدید Application Owner ، EMC از EMC Data Protection Advisor نیز جهت توانمند سازی و افزایش دامنه دید Backup Admin استفاده کرده است. DPA با بهره گیری از پایش، تحلیل و گزارشات خودکار خود، می تواند یک چشم انداز جامع از محیط حفاظت شده را پیش روی Backup Admin قرار دهد.

دیگر نیازی نیست که  Application Ownerنگرانی از بابت SLA داشته باشند، زیرا DD Boost for Enterprise امکان دسترسی و کنترل مستقیم فرآیندهای بکاپ را برای آنها فراهم آورده است و بدین گونه آنها هر لحظه می توانند در جریان این گونه اطلاعات باشند. همانگونه که Application Owner به مدیریت پایگاه های داده ای نظیر  Oracle RMAN، Microsoft SQL Server، SAP، SAP HANA و یا IBM DB2 می پردازد، با ابزارهایی بسیار مشابه نیز می تواند به مدیریت فرآیند بکاپهای مربوط موجود بروی Data Domain بپردازد. پس خداحافظ Storage Silos ها و خداحافظ روزهای بکاپ های بیهوده و اضافی!

Backup Admin ها و  Application Ownerها، هر دو به اتفاق آرا معتقدند که راهکار DD Boost for Enterprise باعث ساده سازی فرآیندها در دیتا سنترها شده اند. و همگی به این موضوع اذعان دارند که این راهکار با بهره گیری از تکنولوژی Client-Side Deduplication باعث افزایش سرعت و افزایش بهره وری شده است. با توزیع فرآیند پردازش Deduplication به سرور بالادستی، نرم افزار موجود بروی سرور قادر خواهد بود تا قبل از انتقال داده ای بروی بستر شبکه از منحصر بفرد بودن آن اطمینان یافته و از انتقال داده های تکراری و تولید بار بروی بستر شبکه جلوگیری نماید. این شیوه باعث افزایش ۵۰% سرعت تولید نسخ پشتیبان ، ۲۰% الی ۴۰% کاهش بار تحمیلی به سرور و کاهش ۸۰% الی ۹۹% ترافیک شبکه می گردد.

پس اگر شما Application Owner و یا Backup Admin هستید که درگیر Storage Silos ها و یا الویتهای نامعلوم و گمراه کننده شده اید، با بهره گیری از قدرت راهکار  Data Domain Boost for Enterprise می توانید حصار ” Accidental Architecture ” را درهم بشکنید و به سادگی به محافظت از دیتاهای خود بپردازید. این راهکار هم بصورت Stand-Alone و هم بعنوان بخشی از EMC’s Data Protection Suite قابل دسترس است.