یک روز ، یک جمله ...

امروز به هر کاری که قراره انجام بدی، باور داشته باش

10 فروردين

آموزش راهکارهای HA و DR در SQL Server - بخش هفتم مطلب ویژه

در این بخش می خواهیم به شرح Always On بپردازیم. این راهکار به عنوان یک راه حل در جهت پیاده سازی همزمان DRP و HA می باشد.

این راهکار از نسخه 2012 سرویس SQL ایجاد شد و در نسخه 2014 آن به صورت کاملا بهینه شده پیاده سازی گردید.

خبرها حاکی از آن است که در نسخه 2016 این ویژگی فارغ از پیش نیازهای قبلی مانند سرویس دامین، در نسخه های Standard نیز قابل پیاده سازی می باشد.

واژه شناسی در AlwaysOn :

  • AlwaysOn
  • Availability Group (AG)
  • Node
  • Instance (SQL Server Instance)
  • Replica
  • Primary
  • Secondary

واژه AlwaysOn نام مفهومی این معماری می باشد که بر روی سرویس SQL به منظور برقراری شرایط HA قرار داده شده است.

واژه Availability Group یک مفهوم منطقی است که در این مفهوم یک یا چند دیتابیس به منظور برقراری شرایط DR قرار داده می شوند و نیاز آن وجود AlwaysOn می باشد.

واژه Node به سروری گفته می شود که در AlwaysOn Availability Group قرار می گیرد.

واژه Instance به یک بسته نصب شده کامل SQL Server شامل حساب های کاربری، Job ها، دیتابیس های سیستمی و ... گفته می شود.

واژه Replica به مفهومی اطلاق می شود که در آن یک دیتابیس توسط AlwaysOn Availability Group محافظت می شود. Primary Replica دیتابیسی است که فعال بوده و Read / Write بر روی آن انجام می شود و Secondary Replica به دیتابیس هایی گفته می شود که به دیتابیس اصلی متصل بوده و به عنوان یک دیتابیس جایگزین برای دیتابیس اصلی تعریف شده اند و در صورت نیاز می توانند به صورت Read Only Database نیز فعالیت داشته باشند.

نکته: یکی از تفاوت های اساسی بین Mirroring و AlwaysOn در این است که در Mirroring تنها یک دیتابیس Mirror می توان داشت ولی در AlwaysOn بیش از یک دیتابیس Mirror می توان ایجاد کرد.

محافظت از طریق AlwaysOn AG :

ویژگی AG به منظور محافظت سطح دیتابیس می باشد و به لحاظ مفهوم بسیار شبیه به ساختار Mirroring می باشد. این ویژگی با ایجاد یک گروه امکان این را ایجاد می نماید که چندین دیتابیس را به منظور محافظت در قالب یک Single Failover Unit قرار دهیم.

در این ساختار ویژگی به نام Virtual IP در هر Availability Group وجود دارد که یک شناسه به منظور معرفی Primary Node در آن گروه است. براساس این آدرس IP ، تمام Node ها به پورت مشخص شده بر روی این آدرس گوش می دهند و تنها یک Node این پورت را Establish می کند که آن Node به عنوان Primary Node می باشد. با این کار سیستم Auto Failover در مقایسه با ویژگی Mirroring دیگر نیازی به Witness و Quorum نخواهد داشت.

یکی از ویژگی های AlwaysOn AG این است که شما می توانید تعیین کنید که کدام Node به عنوان Secondary Node بعد از بروز رخداد برای Primary Node باشد.

نکته بسیار مهم در این است که این ویژگی ساختاری فارغ از هرگونه مسیر مشترک دارد.

پیاده سازی یک سناریو:

در این سناریو ما چهار Node خواهیم داشت. دو Node به عنوان Failover Partners برای پیاده سازی HA می باشند. در این ویژگی تنها دو Node می توانند درون یک گروه به عنوان Failover Partner قرار گیرند. یکی از آنها یک Read Only Node جهت ایجاد شرایط برای کارهای تحلیلی و دیگری به منظور Remote Disaster Recovery در یک محل دیگر خواهد بود.

نکته: جهت ایجاد ساختار تهیه Backup می توانید از Node های ثانویه استفاده نمایید و میزان درگیری سیستم های اصلی را کاهش دهید. چیزی که تا به قبل از این امکان پذیر نبوده است.

نکته: در این سناریو، ایجاد ساختار HA بین دو Node می باشد و یک Node سوم به منظور DR نیز وجود دارد، اما می خواهیم طوری تنظیم کنیم که فرآیند HA بین دو Node مربوط به این کار رخ دهد.

برای شروع کار می بایست سرویس کلاسترینگ را در تمام Node ها فعال نماییم. سپس روی یک Node این سرویس را اجرا کرده و از منوی سمت راست گزینه Create Cluster را انتخاب می نماییم.

در مرحله بعدی چهار Node را به لیست کلاستر اضافه می نماییم.

مرحله بعدی مربوط به طی فرآیند تاییدیه می باشد که می بایست طی شود.

پس از پایان مرحله تاییدیه، اقدام به ثبت نام برای کلاستر نمایید و در نتیجه مراحل را به پایان رسانید.

نکته: تنها کاری که در سطح سیستم عامل انجام می شود راه اندازی سرویس کلاسترینگ می باشد و نکته قابل توجه در این فرآیند، عدم استفاده از دیسک Quorum می باشد.

حال می بایست به بخش تنظیمات AlwaysOn در سرویس SQL برویم. برای شروع کار ابتدا می بایست SQL Server Configuration را اجرا کرده و با راست کلیک کردن بر روی گزینه SQL Server و انتخاب گزینه Properties اقدام به فعال کردن AlwaysOn High Availability از سربرگ مربوطه نمایید.

این کار می بایست در هر Node که می خواهد در این Availability Group قرار گیرد انجام شود.

نکته: فعالسازی این ویژگی نیازمند راه اندازی مجدد سرویس SQL می باشد، لذا می بایست توجه داشته باشید که قطعی کوتاه مددی در روند سرویس دهی خواهید داشت.

پس از فعالسازی این ویژگی می بایست اقدام به ایجاد Endpoint نمایید. این بخش همانند ایجاد Endpoint در ساختار Mirroring می باشد:

Create ENDPOINT endpoint_mirroring
STATE = STARTED
AS TCP ( LISTENER_PORT = 5022 )
FOR DATABASE_MIRRORING (ROLE=PARTNER);
GO

نکته: بحث وجود حساب کاربری با دسترسی Connect در این مقوله وجود دارد و می بایست لحاظ شود.

ایجاد این تنظیمات در تمام Node ها به مانند ساختار Mirroring الزامی است.

حال می بایست یک نسخه Full Backup و یک نسخه Transaction Log بر روی هر Node از دیتابیس هایی که می خواهیم درون یک گروه قرار دهیم، بازگردانی نماییم. حالت بازگردانی نیز به صورت NORECOVERY می باشد. (دقیقا مانند ساختار Mirroring عمل می نماییم)

پس از اعمال این تنظیمات، می بایست اقدام به ایجاد AG نماییم. فرآیند AG از این بخش به بعد آغاز می شود. برای انجام این کار Query زیر را اجرا نمایید:

Create AVAILABILITY GROUP “Name”
FOR
DATABASE “db name”,”db name”,…
REPLICA ON
‘Secondary Node’ WITH
(ENDPOINT_URL = ‘TCP://………….:5022’,
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, FAILOVER_MODE = MANUAL),
.
.
.
GO

نکات دستورات بالا:

ابتدا یک نام برای AG خود انتخاب نمایید.

در بخش DATABASE نام دیتابیس هایی که می خواهید در این گروه قرار گیرند را مشخص نمایید.

بخش Secondary Node نامی است که برای Node های ثانویه خود انتخاب می نمایید و این بخش را می توانید به تعداد Node های خود تکرار نمایید.

در بخش TCP آدرس مربوط به Node را وارد نمایید.

پس از اجرای دستور بالا، می توانید در زیرمجموعه AlwaysOn High Availability در لیست درختی SSMS اقدام به مشاهده Node ها و دیتابیس ها نمایید.

در مرحله بعدی موردی که می بایست مدنظر قرار دهید این است که در هر کدام از Node ها می بایست با دستور زیر اقدام به متصل کردن آن Node به گروه AG نمایید:

ALTER AVAILABILITY GROUP “AG NAME” JOIN;

مقدار AG NAME مقداری است که در ابتدای ایجاد AG انتخاب کرده اید.

بعد از این مرحله می بایست دیتابیس های خود را به این AG متصل نمایید. برای این کار به ازای هر دیتابیس دستور زیر را اجرا نمایید:

ALTER DATABASE “DB NAME” SET HADR AVAILABILITY GROUP = “AG NAME”

این دستور می بایست در تمام Node های یک گروه اجرا شود.

فرآیندهایی که در این بخش بررسی و اجرا شدند به شرح زیر می باشند:

  1. فعالسازی AG در SQL Server Service برای تمام Node ها
  2. ایجاد Endpoint برای تمام Node ها
  3. ایجاد حساب کاربری با سطح دسترسی Connect برای تمام Node ها
  4. ایجاد AG بر روی Node اصلی
  5. متصل کردن سایر Node ها به این AG
  6. متصل کردن دیتابیس ها به AG

همانطور که در بالا دیدید توسط Query اقدام به ایجاد ساختار AG کردیم، اما ساختار را به صورت Asynchronies و Manual Failover ایجاد کردیم. حال می خواهیم از طریق کنسول SSMS اقدام به تغییر این مقادیر نماییم. برای این کار از زیر مجموعه Availability Groups بر روی گروه ایجاد شده خود (اصلی) دوبار کلیک نمایید تا بخش مشخصات گروه نمایش داده شود. سپس از لیست پایین صفحه می توانید این مقادیر را برای Node های مختلف تغییر دهید.

نکته: پس از اعمال تغییرات بالا، با مشاهده کنسول AG متوجه خواهید شد که Node هایی که از حالت Asynchronies خارج شده اند به صورت Synchronized و Node هایی که در حالت Asynchronies هستند به صورت Synchronizing قرار گرفته اند. در حالت Synchronizing احتمال Data Loss وجود دارد.

در صورتیکه می خواهید به صورت Manual اقدام به Failover کردن نمایید، کافیست بر روی Primary AG راست کلیک کرده و گزینه Failover را انتخاب نمایید. با انتخاب این گزینه محیط Wizard مانندی نمایش داده می شود که می بایست مراحل را طی کنید. نکاتی که در این محیط وجود دارند به شرح زیر است:

لیست Node هایی که شما می توانید به آنها Failover نمایید را به شما نمایش می دهد. هر Node می تواند دارای هشدار باشد و یا به صورت Clean و آماده برای Failover لیست شده باشد.

در بخش بعدی می بایست به Node مدنظر Connect شوید.

در صورت انتخاب Node با هشدار Data loss می بایست در مرحله بعدی اقدام به تایید عمل خود نمایید.

به صورت Query می توانید از دستور زیر جهت Failover استفاده نمایید:

ALTER AVAILABILITY GROUP [نام گروه] FAILOVER;

این دستور می بایست بر روی Node زده شود که می خواهد نقش Primary را به خود بگیرد. حال اگر Node مذکور در حالت Asynchronies باشد می بایست از Query زیر استفاده شود:

ALTER AVAILABILITY GROUP [نام گروه] FORCE_FAILOVER_ALLOW_DATA_LOSS;

تبدیل ساختار Failover از حالت دستی به حالت اتوماتیک:

همانطور که در بالا اشاره شده، از طریق کنسول SSMS می توانید مقادیر مربوط به Failover را تغییر دهید اما برای ایجاد شرایط Failover به صورت اتوماتیک نیاز به یک Listener می باشد. یک Listener در واقع یک شناسه منطقی می باشد. به منظور ایجاد Listener مراحل زیر را طی کنید:

بر روی گروه AG اصلی خود راست کلیک کرده و گزینه Add Listener را انتخاب نمایید.

در بخش DNS Name نام رکورد DNS مربوط به این Virtual IP را وارد نمایید.

در بخش Port به صورت پیش فرض می توانید از پورت 1433 استفاده نمایید و در غیر این صورت می توانید پورت دلخواهی را انتخاب نمایید.

در بخش Network حالت را به Static تغییر دهید.

آدرس IP مربوط به Listener را در جدول پایین صفحه وارد نمایید.

مفهوم این Virtual IP مانند مفهوم Private Network در ساختار Failover Cluster می باشد.

نکته: مانند ساختار Failover Cluster از این پس می توانید برای کنسول SSMS به Virtual IP که ایجاد کرده اید متصل شوید و در آنجا وضعیت مربوط به AG را رصد نمایید.

نکته: چیزی که باعث بروز شرایطی می شود که فرآیند Failover به صورت اتوماتیک رخ دهد کاملا قابل مدیریت می باشد. این ساختار مدیریت دارای 5 سطح است که به آنها Flexible Failover Policy گفته می شود و به شرح زیر می باشند:

  • Server Down (1)
  • Server Unresponsive (2)
  • Server Error (3)
  • Moderate Error (4)
  • Any Eligible Error (5)

با Query زیر می توانید یکی از این سطوح را برای AG مشخص نمایید:

ALTER AVAILABILITY GROUP “نام گروه” SET (FAILURE_CONDITION_LEVEL = #);

بنا به دو دلیل زیر مسئله Automatic Failover بسیار مهم و حساس می باشد:

  1. اقدام به Failover در زمانی که می بایست
  2. عدم اقدام به Failover در زمانی که نمی بایست

بنابراین انتخاب یکی از سطوح بالا می بایست با دقت بسیار زیادی صورت پذیرد.

نکته: در بخش AG Properties و در کنار مقادیری چون Failover و Availability Mode شما امکانی خواهید داشت با نام Readable Secondary که با تغییر این مقدار به YES در صورتیکه آن Node به صورت Secondary قرار گیرد امکان ارائه سرویس به صورت Read Only را خواهد داشت.

اضافه کردن یک دیتابیس به گروه AG :

به منظور اضافه کردن یک دیتابیس جدید به گروه AG کافیست بر روی Availability Databases از زیر مجموعه Availability Groups راست کلیک کرده و گزینه Add Database را انتخاب نمایید.

با این کار محیط Wizard نمایش داده می شود که با طی کردن مراحل آن می توانید دیتابیس های موجود در آن Instance را به گروه AG اضافه نمایید.

نکته ای که می بایست مدنظر قرار دهید این است که دیتابیسی که قرار است درون گروه قرار گیرد می بایست به صورت نسخه Full Backup به همراه Transaction Log بر روی Node های ثانویه قرار داده شوند.

آشنایی با ویژگی Offload کردن فرآیند تهیه Backup ها از دیتابیس ها:

یکی از ویژگی هایی که AG در اختیار شما قرار می دهد این است که می توانید بخشی از سربار فرآیند تهیه Backup از دیتابیس های خود را بر روی Secondary Node ها قرار دهید. برای این منظور بخش Properties مربوط به AG را باز کرده و بر روی گزینه Backup Preferences کلیک نمایید. در این بخش شما انتخاب خواهید داشت:

  • Prefer Secondary
  • Secondary Only
  • Primary
  • Any Replica

گزینه اول این امکان را ایجاد می نماید که فرآیند Backup بر روی Secondary Node ها صورت گیرد و در صورت عدم دسترسی به آنها، این فرآیند بر روی Primary ایجاد می شود.

گزینه دوم صرفا بر روی Secondary Node ها اقدام به انجام فرآیند Backup می نماید و در صورت عدم دسترسی به آن ها این فرآیند متوقف می شود.

گزینه سوم صرفا این فرآیند را بر روی Primary انجام میدهد.

گزینه چهارم فرآیند Backup را بر روی هر Secondary Node اجرا خواهد کرد که در این گزینه و در صورت وجود بیش از یک Node می بایست مشخص نمایید که اولیت بندی Node ها به چه صورت می باشند.

نکته: شرایطی که در گزینه آخر وجود دارد اولیت بندی از 1 تا 100 می باشد که عدد بیشتر معرف اولویت بالاتر می باشد. در نتیجه با تعیین این عدد برای یک Node در کنار در دسترس بودن آن Node می توان این فرآیند را مدیریت کرد.

نکته: جهت مشاهده اینکه فرآیند Backup بر روی کدام Node در حال انجام است کافیست Query زیر را بر روی Node های خود اجرا نمایید:

Select sys.fn_hadr_backup_is_preferred_replica (‘نام دیتابیس’)

در صورت بازگردانی مقدار 1 مشخص می شود که آن Node مسئول فرآیند Backup می باشد.

اضافه کردن یک Node به صورت فقط خواندنی به مجموعه AG :

همانطور که می دانید اضافه کردن یک Node به مجموعه کلاسترینگ ساده می باشد اما نکته ای که در اینجا حائز اهمیت است این است که ما می خواهیم این Node به صورت فقط خواندنی به منظور مدیریت بخش تجزیه و تحلیل یک مجموعه قرار گیرد. به همین دلیل می بایست فرآیندی را طی نماییم که این Node به عنوان یک Secondary Node بدون مقادیر Automatic Failover در مجموعه اضافه گردد و همچنین به عنوان یک Node دارای حق رای برای Failover نباشد.

برای این منظور نیاز به معرفی یک Quorum خواهیم داشت. این Quorum می توانید یک مسیر Share شده در شبکه باشد که تنها Node هایی که قرار است فرآیند Automatic Failover را طی کنند به آن دسترسی داشته باشند.

برای این کار، سرویس Clustering ویندوز را باز کرده و با راست کلیک کردن بر روی گزینه Cluster از لیست درختی سمت چپ و انتخاب گزینه Configure Cluster Quorum Settings از زیر منوی More Actions فرآیند معرفی این مسیر Share شده را طی نمایید.

نکاتی که می بایست در این فرآیند مورد توجه داشته باشید به شرح زیر است:

  1. انتخاب گزینه Advanced Quorum Configuration
  2. انتخاب Node هایی که می خواهید حق رای به آنها بدهید
  3. انتخاب گزینه Configure a file share witness
  4. بعد از طی مراحل بالا می توانید اقدام به اضافه کردن Node جدید خود به کلاسترینگ نمایید.

مانیتور کردن وضعیت AG :

یکی از روش های مانیتور کردن وضعیت AG استفاده از کنسول SSMS می باشد. این کنسول به شما این امکان را می دهد تا ستون های متعددی را به منظور مانیتور کردن AG به کنسول آن اضافه نمایید.

برای این کار در بخش کنسول AG روی گزینه Add/Remove Columns کلیک نمایید تا بتوانید لیست مربوط به ستون های موجود را مشاهده نمایید.

روش های دیگری نیز برای مانیتور کردن وضعیت AG نیز وجود دارد که در زیر به آنها اشاره می کنیم:

  • SCOM (System Center Ops Manager)
  • PerfMon
  • Extended Events (AlwaysOn_Health)
  • 3rd Party Monitoring Tools

عیب یابی AG :

محدوده عیب هایی که ممکن است برای AG رخ دهد به شرح زیر است:

  • Failover Cluster
  • Quorum
  • Mirroring
  • Disconnected Synchronization (Low QoS in Network)
  • Unexpected Failover
  • SQL Server Instance (Common in any Databases)

نکته: در صورتیکه ساختار شبکه شما به گونه ایست که سیستم ها در Subnet های مختلفی قرار گرفته اند، می بایست دسترسی های زیر بر روی فایروال سیستم ها ایجاد شوند:

  • TCP 445, 139 (Clustering)
  • TCP/UDP 464 Between Nodes and DC
  • TCP/UDP 49152 – 65535 Dynamic Ports
  • TCP 1433 SQL Server
  • TCP 5022 Mirror Endpoint
  • UDP 3343, 137 Cluster Administration
  • TCP/UDP 135 MSDTC

نکته: در شبکه های Multi-Subnet در صورتیکه Connection String شما به آدرس Listener در حال اتصال می باشد می بایست تگ زیر نیز در آن قرار داده شود:

MultiSubnetFailover=True

بدون این تگ نیز فرآیند برقراری ارتباط نیز امکان پذیر می باشد اما Latency در شبکه بر روند ارتباط تاثیرگذار خواهد بود.

موارد موجود در AG در نسخه 2016 :

  • Read Only Load Balancing
  • Works on Standard Edition
  • Two Nodes
  • Without any Listener
  • Without any Read Only Secondary Node
  • Multi Auto Failover Partners (More than 2 Failover Partners)
رضا اردانه

مدیریت وب سایت آموزش دیجیتال

نظر دادن

خبرنامه

برای دریافت جدیدترین خبرهای سایت در خبرنامه عضو شوید