ओएस और टेम्पर्ड, बैकअप और स्वैप फ़ाइल को डिस्क से अलग करने के लिए लॉग और डेटा फ़ाइलों को अलग करने के लिए इसका मानक अभ्यास। क्या यह तर्क अभी भी समझ में आता है जब आपके ड्राइव सभी SAN आधारित होते हैं और आपके LUNS को विशिष्ट डिस्क या छापे के सेट पर नक्काशी नहीं की जाती है वे SAN पर ड्राइव की संख्या का सिर्फ हिस्सा हैं और LUN सिर्फ अंतरिक्ष आवंटन है
जवाबों:
लॉग और डेटा ड्राइव में अलग-अलग डेटा एक्सेस पैटर्न होते हैं जो ड्राइव साझा करते समय एक दूसरे के साथ (कम से कम सिद्धांत में) टकराव में होते हैं।
लॉग राइट्स
लॉग एक्सेस में बहुत बड़ी संख्या में छोटे अनुक्रमिक लिखते हैं। कुछ हद तक सरल रूप से, डीबी लॉग रिंग बफ़र होते हैं, जिसमें डिस्क पर विशेष स्थानों के लिए डेटा आइटम लिखने के निर्देशों की एक सूची होती है। एक्सेस पैटर्न में बड़ी संख्या में छोटे अनुक्रमिक शामिल होते हैं जिन्हें पूरा करने की गारंटी दी जानी चाहिए - इसलिए उन्हें डिस्क से लिखा जाता है।
आदर्श रूप से, लॉग एक शांत पर होना चाहिए (यानी किसी और चीज के साथ साझा नहीं) RAID-1 या RAID-10 मात्रा। तार्किक रूप से, आप इस प्रक्रिया को मुख्य DBMS के रूप में लॉग एंट्री और एक या एक से अधिक लॉग रीडर थ्रेड्स के रूप में देख सकते हैं, जो लॉग का उपभोग करते हैं और डेटा डिस्क में परिवर्तन लिखते हैं (व्यवहार में, प्रक्रिया को अनुकूलित किया जाता है ताकि डेटा लिखा जाए जहां संभव हो तुरंत बाहर)। यदि लॉग डिस्क पर अन्य ट्रैफ़िक है, तो इन अन्य एक्सेस द्वारा हेड्स को इधर-उधर ले जाया जाता है और क्रमिक लॉग राइट्स यादृच्छिक लॉग राइट्स बन जाते हैं। ये बहुत धीमे हैं, इसलिए व्यस्त लॉग डिस्क एक हॉटस्पॉट बना सकती है जो पूरे सिस्टम पर एक अड़चन के रूप में कार्य करता है।
डेटा लिखता है
(अपडेटेड) लॉग राइट डिस्क के लिए प्रतिबद्ध होना चाहिए (एक स्थिर मीडिया के रूप में संदर्भित) एक लेनदेन के लिए वैध और प्रतिबद्ध होने के लिए पात्र है। कोई इसे तार्किक रूप से लॉग एंट्री के रूप में देख सकता है और फिर एक अतुल्यकालिक प्रक्रिया द्वारा डेटा पेज को डिस्क पर लिखने के निर्देश के रूप में उपयोग किया जा सकता है। व्यवहार में डिस्क पेज वास्तव में तैयार किए जाते हैं और लॉग प्रविष्टि किए जाने के समय बफ़र किया जाता है, लेकिन लेनदेन के लिए प्रतिबद्ध होने के लिए उन्हें तुरंत लिखे जाने की आवश्यकता नहीं है। डिस्क बफ़र्स को स्थिर मीडिया (डिस्क) को लेज़र राइटर प्रक्रिया द्वारा लिखा जाता है (यह इंगित करने के लिए पॉल रान्डल के लिए धन्यवाद), जो यह टेक्नेट लेख थोड़ा और अधिक विस्तार से चर्चा करता है।
यह एक भारी यादृच्छिक अभिगम पैटर्न है, इसलिए लॉग के साथ समान भौतिक डिस्क साझा करना सिस्टम प्रदर्शन पर एक कृत्रिम अड़चन पैदा कर सकता है। लेन-देन की प्रतिबद्धताओं के लिए लॉग प्रविष्टियों को लिखा जाना चाहिए, इसलिए यादृच्छिक प्रक्रिया इस प्रक्रिया को धीमा कर रही है (यादृच्छिक I / O अनुक्रमिक लॉग I / O की तुलना में बहुत धीमी है) लॉग को क्रमिक से यादृच्छिक एक्सेस डिवाइस में बदल देगा। यह एक व्यस्त प्रणाली पर एक गंभीर प्रदर्शन अड़चन पैदा करता है और इसे टाला जाना चाहिए। लॉग वॉल्यूम के साथ अस्थायी क्षेत्रों को साझा करते समय यही बात लागू होती है।
कैशिंग की भूमिका
सैन नियंत्रकों में बड़े रैम कैश होते हैं, जो कुछ हद तक यादृच्छिक अभिगम यातायात को अवशोषित कर सकते हैं। हालाँकि, लेन-देन की अखंडता के लिए यह आवश्यक है कि डिस्क डीबीएमएस से लिखता है जिसे पूरा करने की गारंटी है। जब कोई नियंत्रक राइट-बैक कैशिंग का उपयोग करने के लिए सेट किया जाता है, तो गंदे ब्लॉक कैश किए जाते हैं और I / O कॉल को होस्ट के रूप में पूर्ण होने की सूचना दी जाती है।
यह बहुत सारी विवाद समस्याओं को सुलझा सकता है क्योंकि कैश बहुत सारे I / O को अवशोषित कर सकता है जो अन्यथा भौतिक डिस्क पर चले जाएंगे। यह RAID-5 के लिए पठन पढ़ता और लिखता है को अनुकूलित कर सकता है, जो RAID-5 संस्करणों के प्रदर्शन पर प्रभाव को कम करता है।
ये वो विशेषताएं हैं जो 'लेट द सैन डील इट विद' स्कूल ऑफ़ थिंक, अलथौग इस दृश्य की कुछ सीमाएँ हैं:
राइट-बैक कैशिंग में अभी भी विफलता मोड हैं जो डेटा खो सकते हैं, और नियंत्रक ने डीबीएमएस को फाइबर्ड किया है, यह कहते हुए ब्लॉक को डिस्क से बाहर लिखा गया है जहां वास्तव में वे नहीं हैं। इस कारण से, आप ट्रांसेक्शनल एप्लिकेशन के लिए राइट-बैक कैशिंग का उपयोग नहीं करना चाह सकते हैं, मिशन-क्रिटिकल या फाइनेंशियल डेटा रखने के लिए कुछ ऐसा जहां डेटा अखंडता की समस्याएं व्यवसाय के लिए गंभीर परिणाम हो सकती हैं।
SQL सर्वर (विशेष रूप से) I / O का उपयोग उस मोड में करता है जहाँ एक ध्वज (जिसे FUA या फ़ोर्स्ड अपडेट एक्सेस कहा जाता है) कॉल रिटर्न्स से पहले डिस्क पर भौतिक लिखता है। Microsoft के पास एक प्रमाणन कार्यक्रम है और कई SAN विक्रेता हार्डवेयर का उत्पादन करते हैं जो इन शब्दार्थों ( यहाँ संक्षेप में प्रस्तुत की गई आवश्यकताओं ) का सम्मान करते हैं । इस स्थिति में कैश की कोई भी राशि डिस्क राइट्स को ऑप्टिमाइज़ नहीं करेगी, जिसका अर्थ है कि लॉग ट्रैफ़िक व्यस्त साझा वॉल्यूम पर बैठे होने पर थ्रैश होगा ।
यदि एप्लिकेशन बहुत सारे डिस्क ट्रैफ़िक उत्पन्न करता है, तो इसका कार्य सेट कैश से अधिक हो सकता है, जो लेखन विवाद समस्याओं का कारण भी होगा।
यदि SAN को अन्य एप्लिकेशन (विशेष रूप से समान डिस्क वॉल्यूम पर) के साथ साझा किया जाता है, तो अन्य एप्लिकेशन से ट्रैफ़िक लॉग की अड़चनें उत्पन्न कर सकता है।
कुछ एप्लिकेशन (जैसे डेटा वेयरहाउस) बड़े क्षणिक लोड स्पाइक उत्पन्न करते हैं जो उन्हें SAN पर काफी असामाजिक बनाते हैं।
यहां तक कि एक बड़े SAN पर अलग लॉग वॉल्यूम अभी भी अनुशंसित अभ्यास हैं। आप हल्के से इस्तेमाल किए गए एप्लिकेशन पर लेआउट के बारे में चिंता न करें। वास्तव में बड़े अनुप्रयोगों पर, आपको कई SAN नियंत्रकों से भी लाभ मिल सकता है। Oracle डेटा वेयरहाउस लेआउट केस स्टडीज़ की एक श्रृंखला प्रकाशित करता है जहाँ कुछ बड़े कॉन्फ़िगरेशन में कई नियंत्रक होते हैं।
प्रदर्शन के लिए जिम्मेदारी जहां यह है
बड़े वॉल्यूम के साथ कुछ पर या जहां प्रदर्शन एक मुद्दा हो सकता है, सैन टीम को आवेदन के प्रदर्शन के लिए जवाबदेह बनाते हैं। यदि वे कॉन्फ़िगरेशन के लिए आपकी सिफारिशों को अनदेखा करने जा रहे हैं, तो सुनिश्चित करें कि प्रबंधन को इस बारे में पता है और सिस्टम के प्रदर्शन की जिम्मेदारी उपयुक्त स्थान पर है। विशेष रूप से, I / O वेट या पेज लैक वेट या स्वीकार्य एप्लिकेशन I / O SLA के जैसे प्रमुख DB प्रदर्शन आँकड़ों के लिए स्वीकार्य दिशानिर्देश स्थापित करें।
ध्यान दें कि कई टीमों में प्रदर्शन विभाजन के लिए जिम्मेदारी होने से उंगली-बिंदु के लिए एक प्रोत्साहन पैदा होता है और दूसरी टीम को हिरन पास होता है। यह एक ज्ञात प्रबंधन विरोधी पैटर्न है और उन मुद्दों के लिए एक सूत्र है जो महीनों या वर्षों तक बिना हल किए खींचे जाते हैं। आदर्श रूप से, एप्लिकेशन, डेटाबेस और SAN कॉन्फ़िगरेशन परिवर्तनों को निर्दिष्ट करने के लिए प्राधिकरण के साथ एक एकल वास्तुकार होना चाहिए।
इसके अलावा, लोड के तहत सिस्टम को बेंचमार्क करें। यदि आप इसे व्यवस्थित कर सकते हैं, तो ईबे पर सेकंडहैंड सर्वर और डायरेक्ट-अटैच एरेज़ काफी सस्ते में खरीदे जा सकते हैं। यदि आप एक या दो डिस्क सरणियों के साथ एक बॉक्स सेट करते हैं, तो आप भौतिक डिस्क कॉन्फ़िगरेशन के साथ फ्रिग कर सकते हैं और प्रदर्शन पर प्रभाव को माप सकते हैं।
एक उदाहरण के रूप में, मैंने एक बड़े सैन (एक आईबीएम शार्क) पर चलने वाले एप्लिकेशन और एक दो-सॉकेट बॉक्स के बीच एक सीधा अटैच U320 सरणी के साथ तुलना की है। इस मामले में, eBay से खरीदे गए £ 3,000 के मूल्य के मूल्य में दो के एक कारक द्वारा £ 1M हाई-एंड SAN को अलग कर दिया गया - लगभग बराबर CPU और मेमोरी कॉन्फ़िगरेशन के साथ एक होस्ट पर।
इस विशेष घटना से, यह तर्क दिया जा सकता है कि इस तरह के आस-पास कुछ होने के कारण SAN प्रशासकों को ईमानदार रखने का एक बहुत अच्छा तरीका है।
मैं यह मान रहा हूँ कि इक्वलोगिक टैग और अनुरोध की सामग्री का अर्थ है कि आप एक समान इलोजिकल सैन के बारे में सोच रहे हैं। क्या विशेष रूप से इक्वलोगिक के बारे में है और यह अन्य SAN प्रकारों पर लागू नहीं होता है।
इक्वैलॉजिक सरणियों के साथ, वॉल्यूम के लिए उपयोग किए जाने वाले विशिष्ट डिस्क को ठीक-ठीक निर्दिष्ट नहीं किया जा सकता है, जैसा कि वे कह सकते हैं, EMC क्लारियन सरणियां इसलिए दृष्टिकोण थोड़ा अलग होना चाहिए।
समतुल्य वास्तुकला बहुत स्वचालित और गतिशील है। इसका मूल बिल्डिंग ब्लॉक एक सरणी इकाई है, जो अन्य SAN में देखे गए सरणी के भीतर RAID पैक नहीं करता है। प्रत्येक सरणी पूरी तरह से RAID 5, 6, 10 या 50 के लिए कॉन्फ़िगर की गई है, हालांकि इसका मतलब यह नहीं है कि प्रति सरणी केवल एक ही RAID समूह है, आप बस उस स्तर पर उनके साथ तय करने या बातचीत करने के लिए कभी नहीं मिलते हैं। आप एरे को स्टोरेज पूल में रखते हैं और आपके पूल फिर एक स्टोरेज ग्रुप के होते हैं। संग्रहण समूह में एक क्लस्टर \ वर्चुअल आईपी-पता होता है जिसे आप उस समूह के भीतर सभी संस्करणों के लिए iSCSI डिस्कवरी लक्ष्य के रूप में उपयोग करते हैं - EQL समूह प्रबंधन सॉफ्टवेयर और होस्ट MPIO स्टैक वास्तव में सबसे उपयुक्त पोर्ट पर रूट करने के लिए आवश्यक आईपी स्तर पुनर्वितरण को संभालता है। अलग-अलग सरणियों जब डेटा के ब्लॉक का अनुरोध करते हैं, लेकिन यह ऐसा कुछ है जिसे आप नियंत्रित करने की बहुत कम या कोई क्षमता नहीं है।
स्टोरेज वॉल्यूम को प्रत्येक पूल में कुल खाली स्थान से सौंपा गया है। एक पूल के भीतर सभी संस्करणों को उस पूल (नेटवर्क पर निर्भर करता है की कुल संख्या में अधिकतम 4 अलग-अलग सरणियों के लिए) में उस पूल (नेटवर्क पर निर्भर करता है 2-4 प्रति Eql सरणी) और IO नेटवर्क में वितरित करने के लिए सभी संस्करणों में फैले हुए हैं। संभव के रूप में कई नियंत्रकों के पार। समतुल्य प्रबंधन सॉफ्टवेयर समय के साथ वॉल्यूम \ सरणी प्रदर्शन की निगरानी करता है और गतिशील रूप से सदस्य सरणियों में ब्लॉकों के वितरण का अनुकूलन करता है। सामान्य तौर पर जब तक आप यह नहीं जानते कि आप क्या कर रहे हैं, आपको सभी एरेज़ को एक ही पूल में रखना चाहिए और इसे अपनी बात करने देना चाहिए, यह सुनिश्चित करने के लिए याद रखें कि आपने RAID 10 के साथ अपने हाई स्पीड डिस्क (SAS 10k \ 15k) को कॉन्फ़िगर किया है, RAID 50 के साथ मध्यम गति या 5 यह सुनिश्चित करने के लिए कि अनुकूलन प्रक्रिया वास्तव में वास्तविक उच्च प्रदर्शन ड्राइव का चयन करती है।
मोटे तौर पर अनुमान के अनुसार, आपके पास ड्राइव प्रकार और RAID प्रकार के आधार पर पीएस सरणी प्रति 2500-5000 IOP के बीच कहीं होगा। यदि आप पर्याप्त कुल IOP प्रदान करते हैं, तो स्वचालित प्रबंधन प्रक्रिया को अंततः आपको अच्छा प्रदर्शन देना चाहिए, भले ही आप बस एक ही पूल में सभी संस्करणों को गांठ दें।
हालाँकि यदि आप गारंटी देना चाहते हैं कि आपके लॉग, डेटाबेस, अस्थायी स्टोर, ओएस ड्राइव आदि वास्तव में एक दूसरे से अलग हैं तो आप कुछ चीजें कर सकते हैं। सबसे पहले आप एक वॉल्यूम के लिए एक RAID वरीयता को परिभाषित कर सकते हैं जो गारंटी देगा कि विशिष्ट वॉल्यूम हमेशा उस RAID प्रकार के सरणियों पर संग्रहीत किया जाता है (यदि वे पूल में मौजूद हैं जो वॉल्यूम से संबंधित है)। दूसरे आप टियर स्टोरेज पूल को परिभाषित कर सकते हैं जिसमें केवल एरे होते हैं जो उस विशेष श्रेणी के लिए आपके द्वारा आवश्यक प्रदर्शन के विभिन्न ग्रेड प्रदान करते हैं और फिर आपके वॉल्यूम को उपयुक्त पूल में वितरित करते हैं। इस दृष्टिकोण के साथ आने वाली स्वास्थ्य चेतावनी है कि वास्तव में बेहतर समग्र प्रदर्शन देने के लिए आपको आम तौर पर बहुत सारे सरणियों की आवश्यकता होगी - जो कि आपके महत्वपूर्ण संस्करणों पर प्रदर्शन की गारंटी देने की तुलना में आपके लिए कम महत्वपूर्ण हो सकता है, हालांकि यह अभी भी सबसे अच्छा है चुनाव। Oracle DB के लिए डेल का संदर्भ आर्किटेक्चर डेटा, वोटिंग डिस्क और OCR के लिए 2 RAID 10 सरणियों के साथ एक पूल का उपयोग करता है, और फ्लैश रिकवरी क्षेत्र के लिए एक एकल RAID 5 सरणी के साथ एक अलग पूल है।
समतुल्य समय के साथ सभी बिंदुओं पर आपको अपने आप से पूछना चाहिए कि क्या आप जिन निर्णयों को लागू करने के संबंध में निर्णय ले रहे हैं, वे उपलब्ध नेटवर्क इंटरफेस, डिस्क स्पिंडल और नियंत्रक के संदर्भ में आपके संस्करणों के लिए बेहतर समग्र प्रदर्शन प्रदान करने वाले हैं। यदि आप इसका उत्तर नहीं दे सकते हैं, तो न्यूनतम संख्या में पूल का चयन करें और इसे छोड़ दें कि विवरण को संभालें या वास्तविक डिजाइन करने के लिए एक समान विशेषज्ञ प्राप्त करें। यदि आपके पास केवल एक ही सरणी है तो अलग-अलग वॉल्यूम के संदर्भ में आप कुछ भी नहीं कर सकते हैं।
हम अपने DBs को सिंगल SAN बॉक्स पर स्टोर करते हैं, लेकिन अलग-अलग डेटा, लॉग और बैकअप LUN के साथ, प्रत्येक डिस्क पर अलग-अलग, गति द्वारा tiered - हमारे लॉग ऑन है RAID 10 15Krpm LUN, डेटा पर RAID 1 10 / 15kpmpm LUN और बैकअप RAID 5 7.2krpm LUNs। हम समान SAN पर विभिन्न नियंत्रकों के माध्यम से लॉग और डेटा भी प्रस्तुत करते हैं।
बड़ा अच्छा सवाल!
पहले इस मुद्दे पर ब्रेंट ओजर की "स्टील केज ब्लॉगमैच" बहस पर एक नज़र डालें ।
हमारी कंपनी में, अधिकांश सर्वरों के लिए, हम डेटा और लॉग्स को एक ही SAN ड्राइव पर रखते हैं, और यह सुनिश्चित करने के लिए SAN टीम पर छोड़ देते हैं कि सब कुछ सही काम करता है।
मुझे लगता है कि यह सबसे अच्छी रणनीति नहीं है, खासकर उच्च-मात्रा वाले सर्वर के लिए। अंतर्निहित समस्या यह है कि मेरे पास वास्तव में यह सत्यापित करने का कोई तरीका नहीं है कि SAN टीम वास्तव में हमारे द्वारा आवश्यक स्थान के लिए पर्याप्त ड्राइव को एक साथ थप्पड़ मारने से अधिक कुछ भी नहीं कर रही है। हम अपनी ओर से या कुछ भी से SAN ड्राइव के खिलाफ IO बेंचमार्क नहीं चलाते हैं, हम केवल यह मानते हैं कि वे "अपना काम कर रहे हैं" (प्रदर्शन के साथ-साथ अंतरिक्ष के लिए समायोजन), जो शायद थोड़ा सा भोला है।
मेरे अन्य विचार यह है कि तरह के लिए उपयोग की है कि डेटा लॉग बनाम जरूरत अलग है। मैं हाल ही में पढ़े गए लेख को खोजने की कोशिश करूंगा जो इस बारे में बात कर रहा था कि दो अलग-अलग ड्राइव प्रकारों को वास्तव में बहुत अलग तरीकों से कैसे अनुकूलित किया जाना चाहिए (मुझे लगता है कि अनुक्रमिक लिखने के लिए एक आवश्यक अनुकूलन है, यादृच्छिक पढ़ने के लिए अन्य आवश्यक अनुकूलन, कुछ इस तरह से। ।)
संक्षेप में, हाँ, आप SQL सर्वर डेटा फ़ाइलों, लॉग फ़ाइलों और TempDB डेटा और लॉग फ़ाइलों के लिए अलग-अलग वॉल्यूम बनाएंगे।
चूँकि आपने अपने प्रश्न को इक्वलॉजिक के साथ टैग किया है, कृपया अपने समाधान को डिज़ाइन करने से पहले डेल ™ इक्वललॉजिक ™ PS5000 सीरीज स्टोरेज एरेज़ (पंजीकरण आवश्यक) के साथ Microsoft® SQL Server® को नि : शुल्क डेल संदर्भ वास्तुकला गाइड के माध्यम से पढ़ें । अक्सर आप पाएंगे कि विशिष्ट कॉन्फ़िगरेशन पर मार्गदर्शन सामान्य सलाह से काफी भिन्न हो सकता है ।
मैं प्रदर्शन के मामले में ब्रैड (+1) से सहमत हूं। आम तौर पर, एक अच्छा SAN अधिक कच्चा I / O होता जिससे आप उपयोग करने की अपेक्षा कर सकते हैं।
अपने लाइव सिस्टम से अपने BACKUP को अलग करना अभी भी एक अच्छा विचार है (स्पष्ट रूप से मुझे पता है, लेकिन अगर मुझे हर बार यह देखने के लिए £ 1 था ...)
इसके अलावा, टेम्पपब को लॉग फाइलों से दूर रखने की सिफारिश की जाती है। जब आप लॉग्स, डेटा और टेंप के लिए "अलग-अलग बाल्टियाँ" (तकनीकी शब्द) चाहने लगते हैं, तो सैन के डेरे ने आप पर अपनी आँखें फेरनी शुरू कर दीं, लेकिन अगर आप उन्हें बताएं कि आप अलग-अलग मात्रा में डेटा प्राप्त कर सकते हैं, तो आप प्रत्येक क्षेत्र में जा रहे हैं। उन्हें आप अपने फैंसी प्रदर्शन रेखांकन दिखाने के लिए जाओ!
बस डबल / डबल जांचें कि SAN पुरुष ने इसे आपके लिए सही सेट किया है। यदि आप RAID 10 चाहते हैं, तो उस पर जोर दें (मैंने किया) भले ही वे कहते रहे कि उनके RAID 5 में कोई प्रदर्शन दंड नहीं है।
("फ़ाइल आधारित" संचालन के लिए, RAID 5 ठीक है। गहन लेखन के लिए, जैसे ही आप लिखते हैं कि बफ़र आपके खराब हो गए हैं!)
सभी शर्तों के सम्मिश्रण से अवगत रहें
आम तौर पर, और बहुत बुनियादी:
एक ही सरणी पर आपके पास कई वॉल्यूम हो सकते हैं, जब आप इस थ्रेड में चर्चा किए गए उच्च-श्रेणी के अनुकूलन कर रहे हों, तो आपको याद रखने के लिए कुछ है।
कुंजी वह है जो कई अन्य लोगों ने उल्लेख किया है (इसे मत भूलना), अलग ड्राइव स्पिंडल पर डेटा / लॉग / बैकअप अलग करें, न कि केवल अलग-अलग वॉल्यूम।
संपादित करें: और ऊपर दिए गए Helvick ने आपको समान-उत्तर दिए हैं, जो समलॉगिक SAN के बारे में उत्तर देता है!