رفع خطای 1207 SQL Server: راهنمای جامع برطرف کردن مشکل در دسترس نبودن Quorum در WSFC

رفع خطای 1207 SQL Server: راهنمای جامع برطرف کردن مشکل در دسترس نبودن Quorum در WSFC

خطای 1207 در SQL Server با پیام “Quorum resource unavailable” یکی از خطاهای حیاتی و نشان‌دهنده مشکلی جدی در زیرساخت Windows Server Failover Cluster (WSFC) است. این خطا به طور مستقیم بر روی عملکرد سرویس‌های SQL Server که بر بستر کلاستر پیاده‌سازی شده‌اند، از جمله SQL Server Failover Cluster Instances (FCIs) و Always On Availability Groups (AGs)، تأثیر می‌گذارد. درک مفهوم Quorum برای رفع این خطا بسیار ضروری است. Quorum مکانیزمی حیاتی در کلاسترهای Failover است که برای جلوگیری از پدیده‌ای به نام “Split-Brain” (شکاف مغزی) طراحی شده است. Split-Brain زمانی رخ می‌دهد که کلاستر به دو یا چند بخش تقسیم شده و هر بخش تصور می‌کند که کنترل منابع را در دست دارد، که منجر به ناسازگاری داده‌ها و خرابی می‌شود. Quorum با اطمینان از اینکه تنها یک بخش از کلاستر می‌تواند به عنوان کلاستر اصلی عمل کند و منابع را آنلاین نگه دارد، این مشکل را حل می‌کند. به عبارت دیگر، Quorum مجموعه‌ای از رأی‌ها در کلاستر است که برای تصمیم‌گیری در مورد اینکه کدام گره‌ها (Nodes) یا مجموعه‌ای از گره‌ها دارای صلاحیت کافی برای اجرای سرویس‌های کلاستر هستند، استفاده می‌شود. هنگامی که خطای 1207 رخ می‌دهد، به این معنی است که کلاستر نتوانسته است به تعداد کافی رأی برای حفظ Quorum و ادامه فعالیت دست یابد، در نتیجه سرویس‌های SQL Server مرتبط با آن نیز از دسترس خارج می‌شوند یا قادر به شروع به کار نیستند. این وضعیت می‌تواند منجر به قطعی سرویس و عدم دسترسی به پایگاه‌های داده شود.

علل اصلی خطای 1207 Quorum Resource Unavailable

دلایل مختلفی می‌توانند منجر به بروز خطای 1207 و از دسترس خارج شدن منبع Quorum شوند. شناسایی علت اصلی، اولین قدم در مسیر رفع این مشکل است:

* **خرابی یا از دسترس خارج شدن منبع Quorum:** این رایج‌ترین علت است. منبع Quorum می‌تواند به یکی از اشکال زیر باشد:
* **Disk Witness (شاهد دیسک):** یک دیسک کوچک در ذخیره‌سازی مشترک که به عنوان یک رأی دهنده عمل می‌کند. اگر این دیسک خراب شود، آفلاین شود، یا اتصال شبکه به آن قطع شود، Quorum تحت تأثیر قرار می‌گیرد.
* **File Share Witness (شاهد اشتراک فایل):** یک اشتراک فایل در یک سرور دیگر که به عنوان رأی دهنده استفاده می‌شود. مشکلاتی مانند از کار افتادن سرور میزبان اشتراک فایل، قطعی شبکه به سمت آن سرور، تغییر مجوزهای دسترسی به اشتراک، یا پر شدن دیسک سرور میزبان اشتراک می‌توانند باعث بروز خطا شوند.
* **Cloud Witness (شاهد ابری):** یک منبع ابری (مثلاً Azure Blob Storage) که به عنوان رأی دهنده عمل می‌کند. مشکلات ارتباط با سرویس ابری، تغییر کلیدهای دسترسی، یا پیکربندی نادرست در پورتال ابری می‌توانند Quorum را مختل کنند.
* **تعداد ناکافی گره‌های فعال (Insufficient Active Nodes):** Quorum بر اساس تعداد رأی گره‌های آنلاین و منبع شاهد محاسبه می‌شود. اگر تعداد گره‌هایی که در کلاستر آنلاین هستند به حدی نباشد که به حد نصاب رأی برای حفظ Quorum برسند، کلاستر آفلاین خواهد شد. برای مثال، در یک کلاستر سه گره‌ای با Disk Witness، اگر دو گره از کار بیفتند، گره باقی‌مانده به تنهایی نمی‌تواند Quorum را حفظ کند زیرا تنها یک رأی از سه رأی (یک گره + یک دیسک) را در اختیار دارد (نیاز به حداقل دو رأی).
* **مشکلات شبکه و ارتباطات بین گره‌ها یا با منبع شاهد:** ارتباط صحیح بین گره‌های کلاستر و همچنین بین گره‌ها و منبع Quorum (چه دیسک، چه اشتراک فایل، چه ابری) حیاتی است. قطعی کابل شبکه، سوئیچ‌های معیوب، کارت‌های شبکه مشکل‌دار، تنظیمات نادرست IP، یا ترافیک بیش از حد شبکه می‌توانند باعث شوند گره‌ها نتوانند به یکدیگر یا به منبع Quorum دسترسی پیدا کنند.
* **پیکربندی نادرست Quorum:** گاهی اوقات، نوع Quorum به درستی برای محیط کلاستر انتخاب نشده است. مثلاً استفاده از File Share Witness در محیطی که سرور میزبان آن اشتراک فایل نیز ممکن است در معرض خرابی قرار گیرد، می‌تواند مشکل‌ساز باشد. عدم فعال‌سازی Quorum پویا (Dynamic Quorum) در نسخه‌های جدیدتر Windows Server نیز می‌تواند در سناریوهای خاصی باعث از دست رفتن Quorum شود.
* **مشکلات فایروال و مجوزها:** Windows Firewall (یا فایروال‌های سخت‌افزاری) می‌توانند ارتباطات لازم بین گره‌ها و منبع Quorum را مسدود کنند. همچنین، برای File Share Witness، مجوزهای NTFS و Share برای حساب کاربری کامپیوتر گره‌های کلاستر باید به درستی تنظیم شده باشند تا بتوانند به اشتراک فایل دسترسی داشته باشند.
* **مشکلات Active Directory:** در برخی موارد نادر، مشکلات مربوط به Computer Object کلاستر در Active Directory یا DNS می‌تواند بر روی عملکرد کلاستر و در دسترس بودن Quorum تأثیر بگذارد.

راهکارهای عملی برای رفع خطای 1207 SQL Server

رفع خطای 1207 نیازمند یک رویکرد سیستماتیک برای تشخیص و حل مشکل است. مراحل زیر به شما کمک می‌کند تا این خطا را برطرف کنید:

1. تشخیص اولیه و جمع‌آوری اطلاعات

* **بررسی Event Viewer:** اولین گام، بررسی لاگ‌های رویداد (Event Viewer) است. به خصوص لاگ‌های “System” و “Failover Clustering” را در تمام گره‌های کلاستر بررسی کنید. به دنبال Event ID‌های مرتبط با کلاستر مانند 1006، 1069، 1135، 1205، 1207، 1208، 1209، 1558، و 1564 باشید. این لاگ‌ها اغلب توضیحات دقیق‌تری درباره علت اصلی مشکل Quorum ارائه می‌دهند.
* **بررسی وضعیت کلاستر با PowerShell:** حتی اگر کلاستر به طور کامل آفلاین باشد، می‌توانید با PowerShell اطلاعاتی به دست آورید.

با استفاده از این دستور، می‌توانید وضعیت فعلی پیکربندی Quorum در کلاستر خود را مشاهده کنید:

Get-ClusterQuorum

خروجی این دستور نوع Quorum (مثلاً NodeAndDiskMajority، NodeAndFileShareMajority) و وضعیت منبع Quorum را نشان می‌دهد.

برای مشاهده وضعیت تمامی منابع کلاستر، از دستور زیر استفاده کنید:

Get-ClusterResource

این دستور وضعیت “Offline” یا “Failed” را برای منبع Quorum (مانند “Cluster Disk 1 (Quorum)”) یا منابع دیگر نشان می‌دهد.

2. بررسی و رفع مشکل منبع Quorum

نوع Quorum خود را شناسایی کنید و بر اساس آن، اقدامات لازم را انجام دهید:

* **اگر از Disk Witness استفاده می‌کنید:**
* اطمینان حاصل کنید که دیسک شاهد (Quorum Disk) به صورت فیزیکی به SAN/ذخیره‌سازی مشترک متصل است و مشکلی ندارد.
* در Failover Cluster Manager، وضعیت دیسک شاهد را بررسی کنید. اگر “Offline” است، تلاش کنید آن را آنلاین کنید.
* بررسی کنید که آیا دیسک دارای مشکل سخت‌افزاری یا خطای I/O است یا خیر. لاگ‌های سیستم را برای خطاهای دیسک بررسی کنید.
* **اگر از File Share Witness (FSW) استفاده می‌کنید:**
* اطمینان حاصل کنید که سروری که اشتراک فایل روی آن قرار دارد، فعال و در دسترس است.
* مسیر شبکه (UNC path) به اشتراک فایل را از تمامی گره‌های کلاستر پینگ کنید تا از ارتباط شبکه اطمینان حاصل کنید.
* مجوزهای دسترسی به اشتراک فایل و فولدر (NTFS Permissions) را بررسی کنید. حساب کاربری “CNO” (Cluster Name Object) در Active Directory و همچنین حساب‌های کاربری کامپیوتر گره‌های کلاستر باید دسترسی Full Control به این اشتراک داشته باشند.
* بررسی کنید که فضای دیسک روی سرور میزبان FSW کافی باشد.
* **اگر از Cloud Witness استفاده می‌کنید:**
* اتصال شبکه به سرویس ابری (مانند Azure) را بررسی کنید.
* اطمینان حاصل کنید که Storage Account و کلید دسترسی در Azure تغییر نکرده باشد و معتبر باشد.
* پیکربندی Cloud Witness را در Failover Cluster Manager بررسی کنید.

3. بررسی ارتباطات شبکه و فایروال

* **اتصال شبکه بین گره‌ها:** از تمامی گره‌های کلاستر، یکدیگر را پینگ کنید. مطمئن شوید که آداپتورهای شبکه کلاستر (Public و Private/Heartbeat) به درستی کار می‌کنند و بسته‌های شبکه بین آن‌ها در حال ارسال و دریافت است.
* **تنظیمات فایروال:** Windows Firewall را در تمامی گره‌های کلاستر بررسی کنید. پورت‌های مورد نیاز برای Failover Clustering باید باز باشند. به صورت پیش‌فرض، کلاستر از پورت‌های UDP 3343 و TCP 135 استفاده می‌کند، اما پورت‌های دیگری نیز ممکن است برای ارتباطات داخلی کلاستر مورد نیاز باشند. در صورت شک، می‌توانید به طور موقت (برای تشخیص) فایروال را غیرفعال کنید و سپس آن را با تنظیمات صحیح فعال کنید.

4. برگرداندن گره‌های کافی به حالت آنلاین

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

* ابتدا سعی کنید Cluster Service را روی گره‌ای که قبلاً نقش مالک منبع Quorum را داشته است، شروع کنید.
* اگر این کار موفقیت‌آمیز نبود، یا اگر تعداد گره‌های فعال برای حفظ Quorum کافی نیست، ممکن است نیاز باشد تا با یک گره شروع کنید و سپس Quorum را به صورت دستی Force کنید. این اقدام باید با احتیاط فراوان انجام شود.

5. Force کردن Quorum (با احتیاط فراوان)

Forcing Quorum یک اقدام موقتی و اضطراری است که به شما امکان می‌دهد کلاستر را با یک گره (یا حداقل تعداد گره‌های ممکن) شروع کنید، حتی اگر به تعداد رأی کافی برای حفظ Quorum نرسیده باشد. **این کار باید تنها زمانی انجام شود که شما کاملاً از علت اصلی مشکل Quorum آگاه هستید و می‌دانید کدام گره حاوی آخرین وضعیت صحیح کلاستر است تا از پدیده Split-Brain جلوگیری شود.**

* **گام اول:** مطمئن شوید که فقط یک گره در کلاستر فعال است یا قصد دارید آن را فعال کنید. سایر گره‌ها باید متوقف باشند.
* **گام دوم:** دستور PowerShell زیر را روی گره‌ای که می‌خواهید با آن Quorum را Force کنید، اجرا کنید. این گره باید آخرین گره‌ای باشد که آنلاین بوده یا شما از صحت وضعیت کلاستر روی آن اطمینان دارید.

Start-ClusterNode -FixQuorum

این دستور گره را وادار می‌کند تا کلاستر را شروع کند، حتی اگر رأی‌های کافی وجود نداشته باشد.
پس از اجرای این دستور، وضعیت کلاستر را در Failover Cluster Manager بررسی کنید. اگر کلاستر با موفقیت شروع شد، باید بلافاصله دلیل اصلی از دست رفتن Quorum را برطرف کنید و سپس سایر گره‌ها را یکی یکی به کلاستر اضافه کنید.

در صورتی که نیاز به تغییر گره‌ای که Forced Quorum را آغاز می‌کند، داشته باشید، می‌توانید از این دستور برای متوقف کردن Cluster Service بدون تأثیر بر روی Quorum استفاده کنید:

Stop-ClusterNode

و سپس روی گره دیگر `Start-ClusterNode -FixQuorum` را اجرا کنید.

6. بررسی وضعیت Dynamic Quorum

در نسخه‌های جدیدتر Windows Server (2012 R2 و بالاتر)، قابلیتی به نام Dynamic Quorum وجود دارد. این قابلیت به طور خودکار وزن رأی گره‌ها را تنظیم می‌کند و می‌تواند به حفظ Quorum در سناریوهای خاصی (مثلاً در هنگام Shutdown گره‌ها) کمک کند.

* برای بررسی اینکه آیا Dynamic Quorum فعال است یا خیر:

Get-Cluster | Select-Object Name, DynamicQuorum

* برای فعال‌سازی Dynamic Quorum (توصیه می‌شود):

(Get-Cluster).DynamicQuorum = 1

Get-Cluster | Format-List *Quorum*

این دستورات به ترتیب قابلیت Quorum پویا را فعال کرده و سپس وضعیت Quorum کلاستر را به همراه تنظیمات جدید نمایش می‌دهند. فعال بودن Dynamic Quorum در اکثر محیط‌ها به پایداری بیشتر کلاستر کمک می‌کند.

7. بازسازی یا تغییر نوع Quorum

اگر منبع Quorum فعلی به طور مکرر دچار مشکل می‌شود یا به نظر می‌رسد برای محیط شما مناسب نیست، ممکن است نیاز به بازسازی یا تغییر نوع Quorum داشته باشید.

* برای تغییر نوع Quorum به عنوان مثال به NodeAndFileShareMajority:

Set-ClusterQuorum -NodeAndFileShareMajority "مسیر UNC به اشتراک فایل"

به جای `”مسیر UNC به اشتراک فایل”`, مسیر کامل اشتراک فایل خود را وارد کنید (مثلاً `\\FileServer\QuorumShare`).

* برای تغییر نوع Quorum به NodeAndDiskMajority (در صورت داشتن دیسک مشترک):

Set-ClusterQuorum -NodeAndDiskMajority "نام دیسک شاهد"

“نام دیسک شاهد” معمولاً نامی است که در Failover Cluster Manager برای دیسک Quorum نمایش داده می‌شود (مثلاً “Cluster Disk 1”).

8. بررسی SQL Server پس از رفع Quorum

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

* در Failover Cluster Manager، مطمئن شوید که نقش SQL Server (FCI یا AG) در حالت “Running” قرار دارد.
* همچنین می‌توانید از طریق SQL Server Management Studio (SSMS) به اینستنس SQL Server متصل شوید و وضعیت Availability Group یا Failover Cluster Instance را بررسی کنید.
* برای اطمینان از صحت سرویس‌ها در SQL Server، می‌توانید دستورات زیر را اجرا کنید:

SELECT @@SERVERNAME;

SELECT service_name, status_desc FROM sys.dm_server_services;

دستور اول نام سرور فعلی را برمی‌گرداند و دومی وضعیت سرویس‌های SQL Server را نشان می‌دهد.

با پیگیری دقیق این مراحل و توجه به جزئیات مربوط به پیکربندی Quorum و شبکه در محیط خود، می‌توانید خطای 1207 SQL Server را به طور مؤثر برطرف کرده و پایداری کلاستر Failover و سرویس‌های SQL Server خود را بازیابی کنید. پیشگیری از این خطا از طریق طراحی و نگهداری صحیح کلاستر و مانیتورینگ منظم نیز از اهمیت بالایی برخوردار است.