مقدمه بر نحوه کلاسترهای SQL Server

گزینه‌هایی که برای بالا بردن سطح دسترس‌پذیری وجود دارند خیلی متنوع و گیج کننده هستند. من خیلی خوش شانس بودم که در همان ابتدای کارم با کلاسترهای SQL Server آشنا شدم ولی خیلی از مردم این شانس را ندارند تا بتوانند به راحتی اطلاعات اولیه‌ای در مورد کلاسترها و متداول‌ترین مسائلی که ممکن است به هنگام طراحی یک کلاستر رخ دهد کسب کنند.

امروز به شما می‌گویم که کلاستر چیست، برای چه چیزی خوب است و چرا من دوست دارم کلاسترها را به یک روش خاص طراحی کنم. همچنین به شما اطلاعاتی در مورد اینکه کلاستر چه ارتباطی با قابلیت AlwaysOn Availability Groups درSQL Server 2012 دارد و همچنین به سوالاتی که معمولا در زمینه SQL Server پیش می‌آید پاسخ خواهم داد.

در مورد چه نوع کلاسترهایSQL صحبت خواهیم کرد؟

انواع مختلفی از کلاستر وجود دارد. زمانی که SQL Server را کلاستر می‌کنیم، ما یک یا چند instance SQL Server را در یک Windows Failover Cluster نصب می‌کنیم. در این نوشته به طور خاص در مورد کلاستر SQL Server 2005 با Windows Server 2008 صحبت خواهیم کرد.

مفهوم کلیدی: یک Windows Failover Cluster از ذخیره‌سازهای اشتراکی استفاده می‌کند. معمولا این ذخیره‌سازهای اشتراکی بر روی یک SAN قرار دارند. زمانی که یک instance SQL Server بر روی یک کلاستر نصب می‌شود، نیاز است که سیستم و پایگاه‌های داده کاربر در ذخیره‌ساز اشتراکی قرار گیرند. این به کلاستر اجازه خواهد داد که instance SQL را هر زمان که شما درخواست کنید یا زمانی که مشکلی در یکی از گره‌ها به وجود آید، به هر سرور (یا گره) دیگری در کلاستر انتقال دهد. تنها یک کپی از داده وجود دارد، اما نام شبکه و سرویس SQL برای instance می‌تواند از هر گره کلاستری فعال شود.

تفسیر: یک کلاستر failover، این امکان را به شما می‌دهد تا بتوانید تمامی داده‌های یک instance SQL Server را به چیزی شبیه به یک اشتراک (share) که می‌توان آن را از تمامی سرورهای مختلف در دسترس قرار داد اتصال دهید. این معمولا همان نام،SQL Agent jobs، Linked Servers و Logins که در آن به کار گرفته شده است را خواهد داشت. شما حتی می‌توانید کاری کنید که همواره از یک IPAddress و پورت استفاده کنید؛ بنابراین نیاز نیست که کاربران SQL Server در هر زمان از محل آن اطلاع داشته باشند.

در زیر می‌توانید نموداری از یک کلاستر SQL Server را مشاهده کنید. نام کلاستر SQLCLUSTER01 است. این کلاستر دو گره (سرور) به نام‌های SQLCLU01NODE01 و SQLCLU01NODE02 دارد. مردم از طریق SQLCLU01ASQL به instance SQL Server متصل می‌شوند. Instance بر روی پورت ۱۴۳۳ پیکربندی شده است.

 

اووووه خدای من!! در محیط ما اختلالی وجود دارد!

 

اما چرا این اتفاق رخ داد؟ در زیر به شرح آن پرداخته خواهد شد.

سرور SQLCLU01NODE01 به طور ناگهانی از کار افتاد. زمانی که این اتفاق رخ داد، سرویسWindows Failover Cluster متوجه آفلاین شدن این سرور شد. این سبب شد که سرویس‌های SQL Server بر روی SQLCLU01NODE02 قرار گیرد. SQLCLU01ASQL شروع به کار کرد و به همان پایگاه‌های داده در ذخیره‌ساز اشتراکی وصل شد- تنها یک کپی از داده وجود دارد، و جابه جا هم نمی‌شود. به عنوان بخشی از شروع SQL Server startup، هر تراکنشی که در هنگام رخ دادن خرابی هنوز در بین راه بود و تخصیص داده نشده بود، به جای اول خود باز می‌گردد.

وقتی این failover به صورت خودکار رخ می‌دهد، کاربران امکان اتصال به SQLCLU01ASQL را نخواهند داشت. با این وجود، بعد از اینکه SQLCLU01ASQL دوباره شروع به کار کند آنها می‌توانند فعالیت‌های خود را مجددا آغاز کنند، بدون اینکه بدانند که یک سرور هنوز آفلاین است.

چرا کلاسترینگ SQL Server برای شما مهم است؟

اگر شما صاحب یا مدیر یک کسب و کار باشید حتما به کلاستر کردن اهمیت می‌دهید زیرا این امکان را به شما می‌دهد که برنامه‌های خود را برای مدت زمان بیش‌تری آنلاین نگه دارید که این سبب افزایش دسترس‌پذیری پایگاه داده شما خواهد شد.

در زیر می‌توانید چند نمونه از مزایایی که کلاستر کردن برای شما ایجاد می‌کند را مشاهده کنید:

• رخ دادن خرابی سخت‌افزاری برای تک سرورها مثل یک کابوس است. اگر یک سرور در یک کلاستر failover با مشکل مواجه شود، به راحتی می‌توان در زمان رفع این مشکل، SQL Server را اجرا کرد.
• به کارگیری وصله‌های امنیتی در یک تک سرور برای کسب و کار خیلی آزار دهنده است. به هنگامی که سرور در حال شروع مجدد است، SQL Server آفلاین خواهد بود. با استفاده از کلاستر کردن failover، شما می‌توانید وصله‌ها را با زمان از کار افتادگی کمتر برای برنامه‌های خود به کار گیرید؛ زیرا شما SQL Server خود را به گره دیگری منتقل کرده‌اید.
• کلاستر‌های failover، ابزاری اضافی به جعبه‌ابزار عیب‌یابی شما اضافه خواهند کرد. به عنوان مثال: اگر شما به هنگام استفاده از ذخیره‌ساز وقفه زیادی را احساس می‌کنید و تمام موارد موجود را نیز بررسی کرده‌اید ولی به نتیجه نرسیدید، می‌توانید به یک گره دیگر تغییر وضعیت دهید و بررسی کنید که آیا مشکلی با اجزایی که فقط به یک گره تعلق دارند مانند HBA به وجود آمده است یا خیر.
• کلاستر کردن از دید برنامه‌های کاربردی مخفی است. خیلی چیزها تنها باSQL Server کار می‌کنند، بنابراین با سایر جایگزین‌های آن کمی سخت‌تر کار می‌کنند. با کلاستر کردن، تمامی پایگاه‌های داده، لاگین‌ها، agent job ها و هر چیز دیگری که در SQL Server وجود دارد fail over می‌شوند و با هم به یک واحد تبدیل می‌شوند و نیاز به نوشتن فرمان یا هر پیکربندی هیچکدام نیست. علاوه بر این “هماهنگ کننده تراکنش‌های توزیع شده” (distributed transaction coordinator) را نیز می‌توان به خوبی failover کرد.

مسائل و نکات مهم در طراحی یک کلاستر SQL

 

• کلاستر کردن SQL Server چه کارهایی انجام نمی‌دهد؟

اولین مسئله این است که متوجه باشید که کلاستر failover در چه موردی نمی‌تواند به شما کمک کند.

کلاستر کردن کارایی را افزایش نمی‌دهد مگر اینکه شما به هنگام پیاده‌سازی کلاسترینگ، به سرورهای قدرتمند‌تر یا ذخیره‌ساز سریع‌تری انتقال پیدا کنید. اگر اطلاعات شما در یک ذخیره‌ساز محلی باشد، تصور نکنید که با انتقال به یک SAN، کارایی شما به شدت افزایش خواهد یافت. علاوه بر این، کلاسترینگ تضمین نمی‌کند که تمام چیزهایی که در SAN وجود دارد، دارای افزونگی است! اگر ذخیره‌ساز شما آفلاین شود، پایگاه داده شما نیز آفلاین می‌شود.

کلاسترینگ در فضای شما صرفه‌جویی نمی‌کند یا تلاشی برای پشتیبان‌گیری یا تعمیر و نگهداری نمی‌کند و شما همچنان باید تمام عملیات تعمیر و نگهداری را به صورت نرمال انجام دهید.

کلاسترینگ در زمینه افزایش خواندن‌ها (reads) به شما کمکی نمی‌کند. علیرغم اینکه یک SQL Server می‌تواند بر روی هر گرهی در کلاستر اجرا شود، ولی در آن واحد تنها می‌تواند بر روی یک گره اجرا شود. آن ذخیره‌ساز، دیگر توسط هیچ کلاستر دیگری نمی‌تواند خوانده شود.

در نهایت، کلاسترها برای شما آپ تایم ۱۰۰% ایجاد نمی‌کنند. زمانی که SQL Server در حال failover یا انتقال بین گره‌ها است، مدتی از کار می‌افتد.

 

• برای تعیین قرارداد نامگذاری مناسب (Right Naming Convention) وقت بگذارید

در یک کلاستر نام‌های زیادی وجود دارد: یک نام برای خود کلاستر، نام هر کدام از سرورهای کلاستر و نام هر کدام از instance‌ های SQL در کلاستر. این موضوع که شما می‌توانید هر کدام از این نام‌ها را بعدا و زمانی که به یک دسکتاپ راه دور (Remote Desktop) متصل شدید به کار ببرید کمی گیج کننده است؛ بنابراین اگر دقت نکنید ممکن است زمانی پیش بیاید که نتوانید تشخیص دهید که به کدام سرور وارد شده‌اید. من دو قانون عمومی برای نامگذاری دارم:

اول از همه اطمینان حاصل کنید که از نام انتخابی بتوانید تشخیص دهید که نوع تجهیز شما چیست؛ مثلا کلاستر، سرور فیزیکی، سرور SQL یا یک هماهنگ کننده تراکنش‌های توزیع شده (distributed transaction coordinator) است. علاوه بر این من استفاده از BGINFO را پیشنهاد می‌کنم که نام سرور را برای هر سرور موجود در کلاستر نشان می‌دهد.

ثانیا، نامی را برای اجزا انتخاب کنید که اگر بعدا گره یا SQL Server دیگری را به کلاستر نصب کردید این نام‌ها همچنان قابل استفاده باشند.

• از قرار دادن گره‌های بیش از حد در یک کلاستر SQL خودداری کنید

من ترجیح می‌دهم که تنها دو تا سه گره در یک کلاستر قرار گیرد. به عنوان مثال، اگر نیاز به قرار دادن ۵ سرور SQL در کلاستر داشته باشیم، من آنها را در دو کلاستر قرار خواهم داد.

البته اینکار در کل تعداد نام‌ها و آدرس‌های IP را افزایش می‌دهد ولی من آن را به دلایل مدیریتی بیش‌تر ترجیح می‌دهم. زمانی که از وصله‌ها و ارتقا استفاده می‌کنید باید اطمینان حاصل کنید که هر کدام از سرویس‌های موجود در کلاستر شما بعد از تغییرات به خوبی بر روی هر گره اجرا می‌شود. وجود یک کلاستر کوچک‌تر بدین معناست که شما نیاز به failover کردن متعدد بعد از هر تغییر نخواهید داشت.

• فکر نکنید که برنامه‌های کاربردی شما بعد از failover به درستی اتصال مجدد می‌شوند

گرچه SQL Server شما دارای یک نام شبکه و آدرس IP است (اگر از DHCP استفاده نشود)، بسیاری از برنامه‌های کاربردی طوری نوشته نمی‌شوند که بتوانند در صورت بروز وقفه کوتاه مدت در سرور پایگاه داده به خوبی به کار خود ادامه دهند.

مهاجرت به کلاستر failover باید شامل آزمون برنامه کاربردی باشد. گرچه برنامه کاربردی نمی‌داند که در حال صحبت با کلاستر است، ممکن است بعد از failover مجددا اتصال نیابد.

من با یک برنامه کاربردی کار کردم که همه چیز بعد از failover در آن به خوبی پیش می‌رفت، مگر سرورهای وب که دیگر داده‌های گزارش را در پایگاه داده نمی‌نوشتند؛ زیرا طراحی آنها به شکلی نبود که بعد از رخ دادن اختلال مجددا برای اتصال تلاش کنند. داده به صورت آسنکرون نوشته می‌شد و به همین دلیل اختلالی که بر روی کاربران تاثیر بگذارد ایجاد نمی‌شد، ولی به علت اینکه این مشکل به سرعت کشف نشد برخی از داده‌ها از دست رفت.

 

• “Active-Active” می‌تواند سودمند باشد

طرح کلاستر ایده‌آل من، متشکل است از یک کلاستر با دو گره با سخت‌افزار یکسان و دو SQL Server موجود بر روی آن. به این پیکربندی به اصطلاح کلاسترینگ فعال-فعال گفته می‌شود و نام رسمی آن Multi-Instance Failover Cluster است.

بیش‌تر افراد گمان می‌کنند که ایده‌آل‌ترین حالت موقعیتی است که مهم‌ترین SQL Server آنها در یک کلاستر با دو گره قرار بگیرد و دومین گره حاضر، در حال انتظار و بیکار باقی بماند. پس من به چه دلیل به instance SQL Server دوم نیاز دارم؟

من دوست دارم که پایگاه داده حساس و سنگین خود را در یکی از SQL Server های موجود در سرور قرار داده و تعدادی از پایگاه‌های داده غیرحساس و کم مشغله را در دومین SQL Server قرار دهید. بهترین نمونه پایگاه‌های داده برای اینکار، پایگاه‌های داده logging هستند. دو نکته مهم برای این پایگاه‌های داده وجود دارد: اول، آنها نیاز به استفاده از پردازنده و حافظه زیاد برای عملکرد صحیح‌تر ندارند، زیرا من به خوبی می‌دانم که این دو SQL Server می‌توانند به خوبی در حالت بار حداکثر بر روی یک گره اجرا شوند. دوم، پایگاه‌های داده موجود بر روی SQL Server کم مشغله‌تر یا به اصطلاح quiet، در صورت عدم دسترسی نباید باعث آفلاین شدن کل برنامه کاربردی شوند.

چرا من به داشتن یک SQL Server که quiet باشد علاقه دارم؟ زمانی که نیاز به انجام به روز رسانی در ویندوز یا SQL Server دارم، یک کار مشکل پیش رو است. شما می‌توانید rolling upgrades را با کلاسترهای failover اجرا کنید که کار بسیار خوبی است. خوب است بدانید که اگر اولین SQL Server ی که شما بر روی یک گره ارتقا یافته failover می‌کنید مشکلی داشته باشد، همه چیز را کاملا از کار نمی‌اندازد.

نکته: به علت هزینه‌های لایسنس، این گزینه معمولا واقعی به نظر نمی‌رسد. اگر شما این راه را انتخاب کردید، اطمینان حاصل کنید که اگر قرار است همه چیز بر روی تنها یک گره در زمان‌های پر مشغله اجرا شود، می‌تواند در SLA باقی بماند و نباید بر روی quiet SQL Server بار اضافی ایجاد کرد.

 

• دوباره تنظیمات پیکربندی SQL Server خود را ارزیابی کنید

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

آیا حتما باید از کلاسترینگ به منظور استفاده از گروه‌های دسترس‌پذیری (Availability Groups) در SQL Server 2012 استفاده کرد؟

سوال جالبی است. ما یک قابلیت جدید به نام گروه‌های دسترس‌پذیری در SQL Server 2012 داریم که امکان افزایش عملکرد خواندن را فراهم می‌سازد. شما در اکثر مواقعی که نیاز به کلاسترینگ Failover دارید، از عملیات خواندن استفاده خواهید کرد.

به منظور استفاده از قابلیت گروه‌های دسترس‌پذیری در SQL Server 2012، قابلیت کلاسترینگ Failover باید در ویندوز فعال شود. اگر شما از Windows Server 2008 یا ماقبل آن استفاده می‌کنید، این قابلیت تنها در نسخه Datacenter و Enterprise در Windows Server موجود است و بنابراین رایگان نیست؛ ولی این قابلیت در Windows Server 2012 در تمامی نسخه‌ها موجود است.

با وجود اینکه شما قابلیت کلاستر Failover را فعال می‌کنید، نیاز به داشتن ذخیره‌ساز اشتراکی برای استفاده در گروه‌های دسترس‌پذیری ندارید. شما امکان استفاده از یک کلاستر Failover را در یک گروه دسترس‌پذیری دارید، اما می‌توانید در صورت تمایل گروه‌های دسترس‌پذیری خود را با زیر سیستم‌های ذخیره‌سازی کاملا مستقل اجرا کنید. این قابلیت مورد نیاز است زیرا گروه‌های دسترس‌پذیری از بخش‌هایی از کلاسترینگ Failover به منظور مدیریت نام و آدرس IP شبکه مجازی استفاده می‌کنند.

سوالات متداول در مورد کلاسترینگ SQL Server

سوال: آیا می‌توان تمام اجزای SQL Server را روی کلاستر نصب کرد؟

جواب: خیر، سرویس‌های یکپارچه SQL Server، “cluster-aware” نیستند و نمی‌توانند با کلاستر شما fail back وfail forth شوند.

سوال: Failover چقدر زمان می‌برد؟

جواب: عوامل مختلفی در تعیین زمان failover موثر است. برای یک سرویس SQL Server زمان می‌برد که از یک گره بر روی گره دیگر تغییر وضعیت دهد و دوباره شروع به کار کند. این زمان شامل زمان‌های بازیابی پایگاه داده نیز می‌باشد. اگر نیاز باشد که failover ها در SLA نگه داشته شوند، نیاز به آزمایش زمان‌های failover در downtime های طراحی شده دارید و علاوه بر آن باید تخمین بزنید که در صورتی که بار حداکثری روی آن قرار گیرد، failover چقدر زمان می‌برد.

سوال: آیا می‌توانم یک سرور مجازی را کلاستر کنم؟

جواب: بله، شما می‌توانید کلاسترهای failover را با سرورهای مجازی مانند VMware یا Hyper-V بسازید و SQL Server را در آن نصب کنید. یادگیری و آزمایش آن خیلی خوب است ولی ایده خوبی برای استفاده در محیط‌های تولید (production environment) نیست.

سوال: حداقل تعداد گره‌ها در یک کلاستر failover چقدر است؟

جواب: یک، که به آن کلاستر تک گره هم گفته می‌شود. از آن می‌توان برای اهداف آزمایشی استفاده کرد یا زمانی که شما یک کلاستر با دو گره دارید و می‌خواهید کاری را بر روی یک گره انجام دهید. شما می‌توانید یک گره را بدون آسیب زدن به کلاستر خارج کنید.

سوال: آیا می‌توان از geo-clustering برای بازیابی از حادثه استفاده کرد؟

جواب: بله، ولی به برخی تنظیمات نیاز است. بیش‌تر کلاسترهای SQL Server در همان زیر شبکه در یک مرکز داده نصب می‌شوند و برای دسترس‌پذیری بالا بسیار مناسب هستند. “geo-clustering” در SQL Server 2008 در دسترس قرار گرفت و به SQL Server 2012 اضافه شد.

سوال: آیا نسخه ویندوزی که استفاده می‌کنم مهم است؟

جواب: بله، Windows Failover Cluster خود را در آخرین نسخه Windows Server نصب کنید و همچنین به نسخه‌های Enterprise و Datacenter نیز نیاز خواهید داشت. اگر شما باید از نسخه قدیمی‌تر ویندوز استفاده کنید، اطمینان حاصل کنید که حداقل Server 2008 باشد و آخرین service pack ها روی آن نصب شده باشد. Failover Clustering Component در Server 2008 بازنویسی شد، پس اگر شما نسخه‌های قدیمی‌تری را اجرا می‌کنید، قابلیت‌ها و امکانات شما کمتر است.

سوال: Quorum (حد نصاب) چیست؟

جواب: حد نصاب، تعداد اعضای رای دهنده است و در واقع راهی برای بررسی اعضای کلاستری است که حاضر هستند. کلاستر از حد نصاب به منظور تعیین اینکه چه کلاستری باید آنلاین باشد استفاده می‌کند.

منبع:

https://www.brentozar.com/archive/2012/02/introduction-sql-server-clusters/