امروزه اهمیت در دسترس بودن دائمی سرویس ها بر کسی پوشیده نیست، تنها چند ساعت از دسترس خارج شدن دیتابیس می تواند هزینه های زیادی را برای صاحبان سرویس ایجاد کند و باعث از دست دادن دیتا و نارضایتی مشتریانشان شود.
ساده ترین راه برای اینکه مطمئن باشیم در صورت fail کردن سرور و یا دچار مشکل شدن دیتابیس می توانیم اطلاعات را دوباره برگردانیم ایجاد نسخه پشتیبان (Backup ) است. این روش اگر چه مطمئن و کم هزینه است اما عدم دسترسی به سرویس (downtime) ایجاد می کند.
همین امر باعث میشود به این سوال بیاندیشیم که
" بهترین روش برای ایجاد بالاترین سطح در دسترس بودن (High Availability) دیتابیس، چیست؟ "
در این مقاله به بررسی روشهای موجود در Microsoft SQL Server می پردازیم و مزیت ها و معایب هر یک را بیان میکنیم تا بتوانید بهترین و مناسب ترین روش را انتخاب کنید.
روش های مختلف HA) High Availability)
1. Replication
احتمالا نام این روش را شنیده اید یا از آن استفاده کرده اید. در این روش جدول ها و آبجکت های مشخص ( views، Store Procedures و ... ) یک یا چندین SQL را می توان همسان سازی کرد و روشی است که از لحاظ تئوری کامل به نظر می رسد، اما واقعیت این است که که این روش برای HA طراحی نشده است. با این روش می توانید دیتا را روی Instance های مختلف داشته باشید، دیتایی که می خواهید Protect شودرا فیلتر کنید و در گزارش گیری ها از قابلیت های آن بهره ببرید.
این روش برای HA مناسب نیست زیرا:
در هنگام از دسترس خارج شدن دیتابیس اصلی به صورت اتوماتیک به دیتابیس دیگر سوییچ نمیکند. مطمئنن تمایلی ندارید ساعت 2 صبح آخر هفته مجبور شوید تنظیمات تغییر دیتابیس را انجام دهید(البته اگر مشتریتان دولتی نباشد و به سرور در آنزمان دسترسی داشته باشید.)
همچنین در این روش ممکن است در دیتای میان دیتابیس ها اختلاف پیش بیاید، مثلا کاربری عضو سایت شود و قبل replicate شدن دیتا، دیتابیس از دسترس خارج شود به این ترتیب کاربر امکان لاگین کردن نخواهد داشت.
2. Log Shipping
در این روش به جای کپی کردن جدول ها و Stored procedures ها از transaction logs ( شامل هر چیزی است که در دیتابیس اتفاق می افتد) به عنوان منبع اطلاعاتی استفاده میشود و می توان این روش را روی یک یا چندین SQL Servers اعمال کرد.
Shipping در یک بازه زمانی مشخص اتفاق می افتد، به صورت پیش فرض هر 15 دقیقه یکبار است، اما می توان آن را هر یک دقیقه یکبار یا هر یک روز یکبار نیز تنظیم کرد.
با استفاده از این روش شما یک یا چند دیتابیس پشتیبان آماده می توانید داشته باشید.
در این روش هم اگر سرور اصلی از دسترس خارج شود، لازم است تنظیمات به صورت دستی انجام شود و همچنین احتمال از دست دادن دیتا در این روش هم وجود دارد.
این روش در نسخه های
SQL Server 2014, Enterprise, Business Intelligence, Standard, and Web editions پشتیبانی میشود و اما در دنیای واقعی طرفدار چندانی ندارد.
3. Mirroring
Mirroring اولین روشی است که مایکروسافت با هدف ارائه راه حلی برای HA ارائه کرده است.
در این روش دو instance از دیتابیس بر روی سرورهای جداگانه ایجاد میکنیم.
با توجه به خطرات احتمالی ( مثل آتش سوزی) نگهداری هر دو instance در کنار هم و در یک مکان عاقلانه نیست، بهتر است هر instance در یک دیتاسنتر یا مکان جغرافیایی مختلف نگهداری شود.
یکی از دیتابیس ها به عنوان دیتابیس اصلی مشخص میشود و سرور دیگر در حالت آماده باش قرار دارد.
اجرا کردن این دیتابیس ها در حالت high-safety این اطمینان را می دهد که دیتای هر دو دیتابیس دقیقا مشابه است. در این روش درخواستی که از دیتابیس می شود در یک زمان در هر دو دیتابیس اعمال میشود.
چون از یک دیتابیس شاهد (witness server) استفاده می شود، از دست دادن دیتا اتفاق نمی افتد. دیتابیس شاهد یک Microsoft SQL Server جداست که دیتابیس اصلی را مانیتور میکند و در زمان بروز مشکل به روی دیتابیس دوم سوییچ میکند.
اگر ارتباط دیتابیس ها قطع شود آنها اطلاعات خود را از دیتابیس شاهد دریافت میکنند.
از آنجاییکه دیتابیس ها کاملا مشابه و آنلاین هستند،به صورت دستی هم می توان بدون اینکه اتفاقی برای سایت بیفتد بین آنها سوییج کرد.
با این توضیحات این روش ایده آلی به نظر می رسد اما این روش در maintenance Mode قرار گرفته است و در نسخه های جدید Microsoft SQL Server حذف می شود.
مایکروسافت استفاده از Availability Group را به جای آن پیشنهاد کرده است که در ادامه توضیح میدهیم.
4. Always On Failover Clustering
کلاستر (Cluster) در معنای لغوی آن به معنای " یک گروه از چیزهای مشابه یا آدمها که به صورت عمدی یا اتفاقی در کنار هم قرار گرفتند."
Clustering به معنای قرار گرفتن در یک Cluster یا یک گروه نزدیک است.
کلاستر ها چیزی شبیهه SQL Server مشتری را از سخت افزاری که روی آن اجرا شده است، جدا میکنند.
یک نرم افزار اجرا شده از دو قسمت تشکیل شده است : قسمتی در RAM ( هر چیزی که Cached می شود و هر query ای که اجرا میشود) و hard drives ( که دیتابیس در آن قرار دارد)
در یک محیط کلاستر شده، می توانیم پیکربندی (configured) بیش از یک سرور را طوری انجام دهیم که از یک مجموعه hard drive مشترک استفاده کنند به طوری که در یک زمان تنها یک سرور از hard drive ها استفاده کند.
در این روش در هر سرور SQL Server اجرا می شود و یک Hard drive اشتراکی بینشان وجود دارد و زمانیکه سرور اصلی از دسترس خارج شود، Hard drive به سرور دیگر اختصاص داده می شود و کار ادامه پیدا می کند. و این همان چیزی است که به دنبالش هستیم، کمترین زمان پایین بودن سرویس (downtime).
یکی دیگر از مزیت های این روش، زمانی است که می خواهیم سرویس پک جدیدی روی SQL نصب کنیم ( دیتابیس را بروزرسانی کنیم) در حالت عادی لازم است سرویس را متوقف کنیم و دیتابیس از دسترس خارج شود، معمولا اینکار ها را در نیمه شب روزهای تعطیل زمانبندی میکنند که آنهم به معنای حضور ادمین در آن زمان در شرکت است، که چندان خوش آیند نیست.با استفاده از کلاستر، این مسئله به راحتی حل می شود.
سرور A ، SQL را اجرا می کند و سرور B در حالت انتظار قرار دارد و کاری انجام نمی دهد، پس می توان در این زمان آن را بروزرسانی کرد و سپس وظیفه اجرای SQL را به آن سپرد و سرور A را بروزرسانی کرد، به این ترتیب هر دو سرور بدون اینکه کاربران متوجه شوند بروزرسانی می شوند.
خب کمی هم در رابطه با معایب این روش صحبت کنیم، تا بدین جا که همه چیز عالی بوده است.
بزرگترین نقطه منفی این روش هزینه آن است. برای ارائه یک سرویس لازم است دو تا سرور داشته باشید و این یعنی دو برابر شدن هزینه ها !
از طرفی hard drive ها به صورت اشتراکی در این روش بین سرورها قرار می گیرند و اگر مشکلی برایشان پیش بیاید که نیاز به جابجایی داشته باشند بازهم downtime برای سرویس ایجاد می شود.
برای راه اندازی این حالت حداقل از دو سرور استفاده می شود، پس نگرانی بابت خرابی مادربرد، پاور ، مموری یا هرچیز دیگر وجود ندارد اما اگر ساختمان نگهداری سرورها آتش بگیرد چه اتفاقی می افتد؟
از آنجاییکه کلاسترها نیاز دارند با هم در ارتباط باشند بنابراین نمی توانیم آنها را در دو مکان جغرافیایی متفاوت قرار دهیم. راههایی هست که بتوانیم اینکار را انجام دهیم، اما تاخیر ایجاد می کند که خب چندان جالب نیست.
بنابراین اگر نیاز هست که سرورها در مکانهای جغرافیایی مختلف قرار بگیرد ، این روش کارآمد نیست و لازم است از روشهای دیگر مثل Mirroring، Log Shipping یا Availability Group ( در ادامه توضیح داده ایم) استفاده شود.
5. Always On Availability Groups
آخرین روش برای HA، در SQL Server 2012 با هدف فراهم کردن بیشترین میزان دسترسی برای یک یا چند دیتابیس، به جای روش Mirroring، ارائه شد.
مشابه روش Failover Clustering، این روش هم به Windows Clustering وابسته است، بنابراین به یک نقطه مرکزی نیاز دارد تا با دیتابیس ها در ارتباط باشد.
برخلاف روش Failover Clustering، به Shared Storage نیازی ندارد، که این موضوع زمانیکه مشتری بخواهد روی Cloud هاست شودو در هزینه ها صرفه جویی کند اهمیت پیدا میکند.
Availability Group مشابه روش mirroring دیتا را تکثیر می دهد. مشتری می تواند یک سرور با هارد SSD را نزدیک سرور اصلی داشته باشد و دیگری را در یک ناحیه یا یک کشور متفاوت داشته باشد. و از مزایای این روش این است که سرورها را به صورت دستی می توان خارج کرد.
راه اندازی و نگهداری از Availability Group سخت نیست اما با توجه به اینکه Microsoft SQL Server Enterprise نیاز داد و لازم است چند سرور آنلاین و idle داشته باشیم هزینه هنگفتی دارد.
بنابراین این روش بهتر است برای وضعیت های خاص و حساس راه اندازی شود به طوری که هزینه ها یک سرمایه گذاری محسوب شوند.
در این مقاله روش های مختلف HA را از لحاظ هزینه، پیچیدگی و عدم دسترسی اتوماتیک بررسی کردیم. این موارد همان چیزهایی هستند که مشتری ( ادمین دیتابیس ) برای انتخاب بهترین گزینه نیاز دارد.
امیدوارم این مقاله توانسته باشد در این زمینه کمک کننده باشد.