کلاسترینگ در SQL Server از قابلیتهای مهم تلقی میشود و امروزه در کشور ما نیز استفاده کنندگان از این قابلیت هر روز افزایش میابند. سازمانهای دولتی و حتی شرکتهای خصوصی که نیاز به سرویس دهی بدون وقفه دارند، هزینه خرید یک Storage را براحتی تقبل کرده و از مزایای کلاسترینگ بهره مند میشوند.
در محیط کلاستر، اطلاعات به جای دیسک لوکال سرور، روی یک Storage متمرکز میگردد و دو سرور به آن دسترسی خواهند داشت. البته بدان معنی نیست که دو سرور همزمان روی یک درایو یا دیتابیس کار کنند بلکه در آن واحد یکی از دو سرور، مالک درایو خواهند بود و چنانچه سرور مالک، با مشکل مواجه شود آنگاه سرویس کلاستر مالکیت درایو را به سرور دوم منتقل مینماید.
اما در بسیاری از سازمانها بیش از یک سرور وجود دارد که اطلاعات آن دارای حساسیت بالا بوده، در عین حال مایل به کلاستر کردن دیتابیس هستند. متاسفانه دیده ام DBAها در چنین شرایطی خواستار خرید سرور به ازای هر سرور حساس هستند. یعنی با این تفکر که برای هر سرور فعال، سرور دوم یا Failover نیاز است، باید تعداد سرورها را دو برابر کرد!
پشتیبانی SQL Server از معماری N+1 دلیل نوشتن این پست بود. در ساختار N+1 یعنی دارای N سرور مهم هستید که 1 سرور بعنوان Failover برای تمام آنها در نظر گرفته میشود. این سرور میتواند در نبود هر کدام از N سرور، کار را ادامه دهد. در صورتیکه تمام سرورهای فعال با مشکل مواجه شوند و به سرور Failover سوییچ شود، بار آن طبیعتا افزایش محسوسی خواهد داشت. از آنجاییکه چنین اتفاقی بسیار دور از احتمالات است، در محاسبه هزینه/فایده معماری کاملا مطلوبی در آب در می آید!
همچنین معماری N+M قابل پیاده سازی است. یعنی شما N سرور مهم دارید و M سرور یعنی بیش از 1 سرور Failover پیش بینی کرده اید. هر کدام از N سرور فعال میتوانند به بهترین گزینه بین M سرور سوییچ نمایند.
