उपलब्धता समूह संचार के लिए एक समर्पित नेटवर्क को कॉन्फ़िगर करना

SQL सर्वर 2012 ऑलवेजऑन उपलब्धता समूह को प्रत्येक SQL सर्वर आवृत्ति के लिए एक डेटाबेस मिररिंग एंडपॉइंट की आवश्यकता होती है जो एक उपलब्धता समूह प्रतिकृति और/या डेटाबेस मिररिंग सत्र की मेजबानी करेगा। यह SQL सर्वर इंस्टेंस एंडपॉइंट तब एक या अधिक उपलब्धता समूह प्रतिकृतियों और/या डेटाबेस मिररिंग सत्रों द्वारा साझा किया जाता है और प्राथमिक प्रतिकृति और संबंधित माध्यमिक प्रतिकृतियों के बीच संचार के लिए तंत्र है।

प्राथमिक प्रतिकृति पर डेटा संशोधन कार्यभार के आधार पर, उपलब्धता समूह संदेश थ्रूपुट आवश्यकताएं गैर-तुच्छ हो सकती हैं। यह गतिविधि समवर्ती अनुपलब्धता समूह गतिविधि से यातायात के प्रति भी संवेदनशील है। यदि थ्रूपुट अवक्रमित बैंडविड्थ और समवर्ती ट्रैफ़िक के कारण पीड़ित है, तो आप उपलब्धता समूह ट्रैफ़िक को उपलब्धता प्रतिकृति होस्ट करने वाले प्रत्येक SQL सर्वर इंस्टेंस के लिए अपने स्वयं के समर्पित नेटवर्क एडेप्टर से अलग करने पर विचार कर सकते हैं। यह पोस्ट इस प्रक्रिया का वर्णन करेगी और संक्षेप में यह भी बताएगी कि आप निम्नीकृत थ्रूपुट परिदृश्य में क्या देखने की उम्मीद कर सकते हैं।

इस लेख के लिए, मैं एक पाँच नोड वर्चुअल अतिथि Windows सर्वर फ़ेलओवर क्लस्टर (WSFC) का उपयोग कर रहा हूँ। WSFC में प्रत्येक नोड का अपना स्टैंड-अलोन SQL सर्वर इंस्टेंस है जो गैर-साझा स्थानीय भंडारण का उपयोग करता है। प्रत्येक नोड में सार्वजनिक संचार के लिए एक अलग वर्चुअल नेटवर्क एडेप्टर, WSFC संचार के लिए एक वर्चुअल नेटवर्क एडेप्टर और एक वर्चुअल नेटवर्क एडेप्टर है जिसे हम उपलब्धता समूह संचार के लिए समर्पित करेंगे। इस पोस्ट के प्रयोजनों के लिए, हम प्रत्येक नोड पर उपलब्धता समूह समर्पित नेटवर्क एडेप्टर के लिए आवश्यक जानकारी पर ध्यान केंद्रित करेंगे:

एक समर्पित एनआईसी का उपयोग करके एक उपलब्धता समूह की स्थापना लगभग एक साझा एनआईसी प्रक्रिया के समान है, केवल एक विशिष्ट एनआईसी के लिए उपलब्धता समूह को "बाध्य" करने के लिए, मुझे पहले LISTENER_IP निर्दिष्ट करना होगा CREATE ENDPOINT में तर्क मेरे समर्पित एनआईसी के लिए उपरोक्त आईपी पते का उपयोग करते हुए। नीचे पांच WSFC नोड्स में प्रत्येक समापन बिंदु का निर्माण दिखाया गया है:

:CONNECT SQL2K12-SVR1
 
USE [master];
GO
 
CREATE ENDPOINT [Hadr_endpoint] 
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.168.20.31))
    FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES);
GO
 
IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
BEGIN
    ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
END
GO
 
USE [master];
GO
 
GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [SQLSKILLSDEMOS\SQLServiceAcct];
GO
 
:CONNECT SQL2K12-SVR2
 
-- ...repeat for other 4 nodes...

समर्पित एनआईसी से जुड़े इन अंतिम बिंदुओं को बनाने के बाद, उपलब्धता समूह टोपोलॉजी की स्थापना में मेरे बाकी कदम एक साझा एनआईसी परिदृश्य से अलग नहीं हैं।

अपना उपलब्धता समूह बनाने के बाद, यदि मैं प्राथमिक प्रतिकृति उपलब्धता डेटाबेस के खिलाफ डेटा संशोधन लोड चलाना शुरू करता हूं, तो मैं जल्दी से देख सकता हूं कि नेटवर्किंग टैब पर टास्क मैनेजर का उपयोग करके समर्पित एनआईसी पर उपलब्धता समूह संचार यातायात बह रहा है (पहला खंड थ्रूपुट है समर्पित उपलब्धता समूह एनआईसी के लिए):

और मैं विभिन्न प्रदर्शन काउंटरों का उपयोग करके आँकड़ों को भी ट्रैक कर सकता हूँ। नीचे की छवि में, Inetl[R] PRO_1000 MT नेटवर्क कनेक्शन _2 मेरा समर्पित उपलब्धता समूह NIC है और इसमें दो अन्य NIC की तुलना में NIC ट्रैफ़िक का अधिकांश हिस्सा है:

अब उपलब्धता समूह यातायात के लिए एक समर्पित एनआईसी होना गतिविधि को अलग करने और सैद्धांतिक रूप से प्रदर्शन में सुधार करने का एक तरीका हो सकता है, लेकिन यदि आपके समर्पित एनआईसी में अपर्याप्त बैंडविड्थ है, जैसा कि आप उम्मीद कर सकते हैं कि प्रदर्शन प्रभावित होगा और उपलब्धता समूह टोपोलॉजी का स्वास्थ्य खराब हो जाएगा।

उदाहरण के लिए, मैंने प्राथमिक प्रतिकृति पर समर्पित उपलब्धता समूह एनआईसी को 28.8 केबीपीएस आउटगोइंग ट्रांसफर बैंडविड्थ में बदल दिया, यह देखने के लिए कि क्या होगा। कहने की जरूरत नहीं है, यह अच्छा नहीं था। उपलब्धता समूह एनआईसी थ्रूपुट में काफी गिरावट आई:

कुछ ही सेकंड के भीतर, विभिन्न प्रतिकृतियों का स्वास्थ्य खराब हो गया, कुछ प्रतिकृतियां "सिंक्रनाइज़ नहीं कर रही" स्थिति में चली गईं:

मैंने प्राथमिक प्रतिकृति पर समर्पित एनआईसी को 64 केबीपीएस तक बढ़ा दिया और कुछ सेकंड के बाद एक प्रारंभिक कैच-अप स्पाइक भी था:

जबकि चीजों में सुधार हुआ, मैंने इस निचले एनआईसी थ्रूपुट सेटिंग में समय-समय पर डिस्कनेक्ट और स्वास्थ्य चेतावनियां देखीं:

प्राथमिक प्रतिकृति पर संबंधित प्रतीक्षा आँकड़ों के बारे में क्या?

जब समर्पित एनआईसी पर बहुत अधिक बैंडविड्थ थी और सभी उपलब्धता प्रतिकृतियां स्वस्थ स्थिति में थीं, तो मैंने 2 मिनट की अवधि में अपने डेटा लोड के दौरान निम्नलिखित वितरण देखा:

HADR_WORK_QUEUE एक अपेक्षित पृष्ठभूमि कार्यकर्ता थ्रेड का प्रतिनिधित्व करता है जो नए काम की प्रतीक्षा कर रहा है। HADR_LOGCAPTURE_WAIT नए लॉग रिकॉर्ड उपलब्ध होने के लिए एक और अपेक्षित प्रतीक्षा का प्रतिनिधित्व करता है और बुक्स ऑनलाइन के अनुसार, लॉग स्कैन पकड़ा गया है या डिस्क से पढ़ रहा है, तो अपेक्षित है।

जब मैंने उपलब्धता समूह को अस्वस्थ स्थिति में लाने के लिए एनआईसी के थ्रूपुट को काफी कम कर दिया, तो प्रतीक्षा प्रकार वितरण इस प्रकार था:

अब हम एक नया शीर्ष प्रतीक्षा प्रकार देखते हैं, HADR_NOTIFICATION_DEQUEUE . यह उन "केवल आंतरिक उपयोग" प्रतीक्षा प्रकारों में से एक है जैसा कि Books Online द्वारा परिभाषित किया गया है, जो एक पृष्ठभूमि कार्य का प्रतिनिधित्व करता है जो WSFC सूचनाओं को संसाधित करता है। मजे की बात यह है कि यह प्रतीक्षा प्रकार सीधे किसी समस्या की ओर इशारा नहीं करता है, और फिर भी परीक्षण इस प्रतीक्षा प्रकार को अवक्रमित उपलब्धता समूह संदेश थ्रूपुट के साथ शीर्ष पर बढ़ाते हुए दिखाते हैं।

तो नीचे की रेखा आपकी उपलब्धता समूह गतिविधि को एक समर्पित एनआईसी से अलग कर रही है यदि आप पर्याप्त बैंडविड्थ के साथ नेटवर्क थ्रूपुट प्रदान कर रहे हैं तो फायदेमंद हो सकता है। हालांकि यदि आप एक समर्पित नेटवर्क का उपयोग करके भी अच्छी बैंडविड्थ की गारंटी नहीं दे सकते हैं, तो आपके उपलब्धता समूह टोपोलॉजी के स्वास्थ्य को नुकसान होगा।