SQL सर्वर फ़ाइलें स्थानीय या NAS या SAN?

Question

मुझे SQL Server 2008 के साथ एक नया सर्वर स्थापित करना है, आप क्या सलाह देते हैं, एक सर्वर RAID 10 या एक एनएएस में फाइलें?

ISCSI के बारे में मुझे क्या उपयोग करना चाहिए?

सैन के बारे में क्या?

सर्वर में 4 जी रैम है और यह डेटाबेस फाइल लगभग 2 जीबी है।

आज अपने आप को स्पष्ट करने के लिए सर्वर में कोई RAID नहीं है, मुझे किसी प्रकार की रणनीति को लागू करना होगा ताकि अगर मैं कुछ खुशी से अपनी फाइलें सुरक्षित रख सकूं, तो मुझे स्थानीय फ़ाइलें, NAS, SAN क्या चुनना चाहिए? किस विकल्प में सबसे अधिक प्रदर्शन है, क्या अधिक सुरक्षित है?

Comments

यह पूछने की तरह है कि "मुझे अपने नए सर्वर में कितना रैम ऑर्डर करना चाहिए?" - यह एक असंभव सवाल है जब तक कि आप अपने उपयोग, आवश्यकताओं आदि के बारे में विस्तार से कुछ स्तर पर नहीं करते हैं

— पोर्टमैन

पोर्टमैन के साथ बिल्कुल सहमत हैं। क्या आप हमें आवश्यकताओं के बारे में अधिक बता सकते हैं? यह पूछने की तरह है, "मुझे किस तरह की कार खरीदनी चाहिए?" और विक्रेता को अपनी आवश्यकताओं को नहीं बता रहा है।

— । ब्रायन केली

Answer 1

NAS

SQL सर्वर के लिए निश्चित रूप से NAS नहीं। SMB / CIFS के पास फ़ाइल लॉकिंग के लिए DBMS का समर्थन करने के लिए पर्याप्त समर्थन नहीं है (कम से कम कुछ साल पहले, ca 2002-2003)। ध्यान दें कि NFS करता है और आप वास्तव में NFS सर्वर पर Oracle के साथ ऐसा कर सकते हैं। हालाँकि, CIFS शेयर पर SQL सर्वर प्रोटोकॉल की सीमाओं के कारण विश्वसनीय नहीं है। हो सकता है कि यह आपको CIFS के माउंटेड शेयरों पर फाइलें डालने की अनुमति भी न दे।

सैन

यह ट्रांजेक्शनल एप्लिकेशन के लिए अच्छा है क्योंकि RAID कंट्रोलर्स पर कैश काफी बड़े काम के सेट को अवशोषित कर सकता है। सैन RAID नियंत्रक आमतौर पर होस्ट-आधारित RAID नियंत्रकों की तुलना में अधिक कैश का समर्थन करेंगे, विशेष रूप से उच्च-अंत किट पर जहां एक RAID नियंत्रक एक मल्टीप्रोसेसर बॉक्स हो सकता है जो सर्वर के रूप में शक्तिशाली है।

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

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

प्रत्यक्ष संलग्न

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

वास्तव में, प्रत्यक्ष संलग्न भंडारण कई कारणों से डेटा वेयरहाउस सिस्टम के लिए सैन से बेहतर होता है:

• डेटा वेयरहाउस ने डिस्क सबसिस्टम पर बड़े क्षणिक लोड स्पाइक्स लगाए। यह उन्हें SAN पर काफी असामाजिक बनाता है क्योंकि वे SAN पर अन्य प्रणालियों के प्रदर्शन को प्रभावित कर सकते हैं।

• उक्त स्ट्रीमिंग टोंटी।

• डायरेक्ट अटैच स्टोरेज SAN स्टोरेज की तुलना में काफी सस्ता है।

डायरेक्ट-अटैच स्टोरेज के लिए एक और बाजार है जब आप एक ऐसे बाजार को बेच रहे हैं जो एक SAN के लिए पर्याप्त पैसा नहीं देगा। यह अक्सर SMB ग्राहकों को बेचे जाने वाले अनुप्रयोगों के लिए सही होता है। एक पॉइंट ऑफ़ सेल सिस्टम या अभ्यास प्रबंधन प्रणाली के लिए, जिसमें छह उपयोगकर्ता होंगे एक SAN शायद ओवरकिल है। इस तरह की स्थिति में कुछ आंतरिक डिस्क के साथ एक छोटा स्टैंड-अलोन टॉवर सर्वर कहीं अधिक उपयुक्त समाधान है।

Answer 2

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

किसी भी उच्च प्रदर्शन फ़ाइल I / O को विंडोज़ शेयरों पर करने से बचें। प्रोटोकॉल ओवरहेड की एक बड़ी मात्रा है जो नाटकीय रूप से थ्रूपुट को धीमा कर देगी। उदाहरण के लिए, सालों पहले मैंने WAN पर एक बड़ी फाइल ट्रांसफर को मापा था ~ विंडोज शेयरों पर एफ़टीपी का उपयोग करके ~ 50% तेजी से।

Comments

जब तक यह एसक्यूएल को समर्पित नहीं होता, मैं सैन से बचता हूं, जो आमतौर पर ऐसा नहीं होता है। SAN तब तक SQL के लिए अच्छा और तेज़ है जब तक आपके पास राइट कैश को हॉगिंग करने वाला कोई अन्य ऐप न हो।

— SqlACID

Answer 3

NAS का उपयोग न करें।

या तो स्थानीय का उपयोग करें (एक अच्छा RAID नियंत्रक के साथ मध्यम अवधि के लिए ठीक है) लेकिन अगर बजट अनुमति देता है, तो एक सभ्य सैन के लिए जाएं। भाग्य के साथ आप अन्य प्रणालियों के साथ SAN को "साझा" करना शुरू कर सकते हैं और प्रारंभिक परिव्यय के अधिकांश को पुनः प्राप्त कर सकते हैं।

4GB RAM अधिकांश प्रणालियों के लिए ठीक है जब तक कि यह एक समर्पित SQL सर्वर (और यह हमेशा होना चाहिए)। यदि आपने पहले से ही इस पर विचार नहीं किया है, तो 64 बिट ओएस और एसक्यूएल सर्वर का उपयोग करें ताकि आप आसानी से पीएई / एडब्ल्यूई सामान के साथ घूमने के बिना अधिक रैम फेंक सकें।

वर्चुअलाइजेशन के बारे में भी सोचें। आपको एक परीक्षण सर्वर की आवश्यकता है? एक देव सर्वर? SP1 की स्थापना का परीक्षण करें? (पहले की पोस्ट के लिए बेशर्म प्लस: sql-server-in-vmware )

Answer 4

2Gb के डेटाबेस आकार के साथ, यहाँ तक कि SAN पर विचार करने का कोई कारण नहीं है। एनएएस काम नहीं करेगा, आपको केवल बैकअप के लिए एनएएस का उपयोग करने के बारे में सोचना चाहिए ताकि आप डेटा के रूप में उसी मशीन पर बैकअप का भंडारण नहीं कर रहे हैं, और ऑफ-साइट भंडारण के लिए एनएएस से प्रतियां बनाना आसान है।

एक छोटे डेटाबेस के साथ, एक RAID 1 या RAID 10. में स्थानीय डिस्क का उपयोग करें। यदि आपका डेटाबेस RAM में फिट बैठता है, तो आपको IO प्रदर्शन के बारे में बहुत चिंतित होने की आवश्यकता नहीं है। 64-बिट विंडो का उपयोग करें और वहां 8 गिग्स रखें। यह ओएस के लिए बहुत कुछ छोड़ देगा और आपको बढ़ने के लिए जगह देगा।

Answer 5

मैं उन प्रणालियों के साथ काम करता हूं जो स्थानीय RAID डिस्क और फाइबर कनेक्ट सैन दोनों का उपयोग करते हैं। SAN एक नया और तेज मशीन होने के साथ भी बेहतर प्रदर्शन करता है। मुझे लगता है कि एक महत्वपूर्ण कारक यह है कि स्थानीय डिस्क की व्यवस्था एक एकल ड्राइव है, इसलिए एसक्यूएल I और O को ओएस और स्वैप फ़ाइल के साथ साझा कर रहा है। यह ड्रैग में भारी योगदान दे रहा है।

जैसा कि @spoulson ने उल्लेख किया है, SAN कहीं बेहतर डिस्क प्रदर्शन प्रदान कर सकता है। न केवल यह एक अलग ड्राइव है, लेकिन यह बहुत तेजी से डिस्क हार्डवेयर पर होने की संभावना है।

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

हमने जो संघर्ष किया है, वह यह है कि सैन डिस्क स्पेस असाइनमेंट को रूढ़िवादी रूप से संभाला जाता है। क्योंकि यह महंगा है क्योंकि वे इसे बाहर नहीं निकालते हैं। EMC SAN के साथ हम उपयोग करते हैं, आप पूरे LUN को डंप किए बिना असाइन किए गए स्थान को पुनः प्राप्त नहीं कर सकते। इसलिए यदि हम पाते हैं कि आवंटित स्थान हमारी आवश्यकता से अधिक है और हम उस स्थान का उपयोग किसी अन्य LUN के लिए करना चाहते हैं, तो हम केवल ओवरसाइज़ को छोटा नहीं कर सकते। हमें इसे छोड़ना होगा और फिर से भरोसा करना होगा। यह एक उत्पादन वातावरण में इतनी अच्छी तरह से काम नहीं करता है।

जैसा कि दूसरों ने सुझाव दिया है, NAS से बचें। आप अपनी डेटा फ़ाइलों को USB बाहरी हार्ड ड्राइव पर रख सकते हैं।

Comments

यदि आपका EMC SAN एक CX4 है, तो बाद में इस वर्ष EMC OS को एक अपडेट जारी कर रहा है, जो डिस्क को सिकोड़ने की विंडोज 2008 की क्षमता के साथ LUN को सिकुड़ने में मदद करेगा।

— बजकर

Answer 6

एक छोटे 2GB डेटाबेस के लिए, एक SAN ओवरकिल होगा।

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

उस ने कहा, मत जाओ और एक भी RAID-10 वॉल्यूम बनाएं और उस पर अपने सभी डेटाबेस फ़ाइलों को डालें। आप कुछ सरल के साथ शुरू कर सकते हैं जैसे: डेटा - 2x 73GB 15K RPM, RAID1 लॉग्स - 2x 73GB 15K RPM, RAID1 बैकअप - एक बड़ा 7200 RPM या RAID1 में एक जोड़ी

यदि आपके पास अपग्रेड करने का बजट है, तो TempDB के लिए एक और अलग वॉल्यूम जोड़ें (यदि आप कोई जटिल रिपोर्टिंग / विश्लेषणात्मक प्रश्न करते हैं) या लॉग वॉल्यूम को अधिक डिस्क दें और इसे RAID10 के रूप में कॉन्फ़िगर करें यदि आपके पास सिस्टम अधिक लेनदेन w / उच्च वॉल्यूम है अद्यतन के।

एक SAN को ड्राइव की समान संख्या के लिए डायरेक्ट-अटैच्ड स्टोरेज की तुलना में 3-4x की लागत होगी। SAN बैकअप / स्नैपशॉट, क्लस्टरिंग समर्थन और LUN माइग्रेशन और विस्तार के लिए कई उन्नत क्षमताएं प्रदान करते हैं। यदि ये आपके लिए महत्वपूर्ण हैं, तो यह अतिरिक्त खर्च के लायक हो सकता है।

Answer 7

अस्वीकरण: एक NAS पर SQL सर्वर डेटाबेस फ़ाइलों को संग्रहीत करने के साथ कई गंभीर समस्याएं हैं। अन्य सभी विकल्प समान हैं, SAN विकल्प चुनना सही है। प्रासंगिक मुद्दों की एक विस्तृत चर्चा MS KB304261 में है । फिर भी यह धागा एक नेटवर्क शेयर पर SQL सर्वर के बारे में अन्य प्रश्नों के लिए एक पकड़ बन गया है, मैं बल्कि SQL सर्वर संस्करणों में NAS समर्थन की स्थिति के संदर्भ में पोस्ट करूंगा।

बहुत से लोग अब MS SQL के साथ NAS का उपयोग करके प्रयोग करते हैं।

यह डिफ़ॉल्ट रूप से निषिद्ध किया जाता था, हालाँकि कोई व्यक्ति MS SQL 2008 और MS SQL 2005 में प्रतिबंध हटा सकता था। MS SQL 2008 R2 के बाद से ऐसा कोई प्रतिबंध नहीं है।

MS SQL 2005 और 2008 में कुंजी ट्रेस ध्वज है जो नेटवर्क शेयरों के उपयोग को प्रतिबंधित करता है। एक जारी कर सकता है

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

वरुण धवन के MSDN ब्लॉग में सितंबर 2010 की पोस्ट में अधिक जानकारी ।

NAS पर कम से कम तकनीकी रूप से SQL सर्वर चलाना संभव है। विकल्प कई कारकों पर निर्भर करता है और ऐसी स्थिति की कल्पना करना मुश्किल नहीं है जहां एक डेटाबेस के लिए भंडारण एनएएस पर आसानी से उपलब्ध हो।

Comments

संभव का मतलब उचित नहीं है; यह प्रश्न वास्तव में पूछ रहा है कि क्या किसी को NAS डिवाइस पर MSSQL DB होस्ट करना चाहिए, जिसका उत्तर लगभग सार्वभौमिक रूप से नहीं है। आप सही हैं कि यह 2008R2 में डिफ़ॉल्ट रूप से संभव है, लेकिन यह अभी भी बीमार है।

— क्रिस एस

@ क्रिस यह धागा एनएएस पर एसक्यूएल सर्वर पर सामान्य प्रश्नों के लिए एक पकड़ बन गया है, नए प्रश्नों को अक्सर डुप्लिकेट के रूप में बंद किया जाता है। मैंने यह दर्शाने के लिए एक डिस्क्लेमर जोड़ा है कि यह उचित नहीं है।

— दिमित्री चुबरोव