SAN कब विचार करें?

हर कोई SAN खरीदने में कूदना चाहता है, कभी-कभी काफी जोश के साथ। SAN, मानना होगा, काफी cool हैं। वे सबसे मज़ेदार और रोमांचक बड़े hardware items में से एक हैं जो अधिकांश IT professionals को अपने shop में रखने का मौका मिलता है। अक्सर SAN रखने की इच्छा “Jones के साथ कदम मिलाने” की बात है, क्योंकि SAN का उपयोग एक status symbol बन गया है – बड़े कारोबारी IT का एक आखिरी गढ़ जो आप केवल एक dedicated server closet में देखते हैं, कभी किसी के घर में नहीं (खैर, लगभग कभी नहीं)। SAN को जोरदार तरीके से promote किया जाता है, आंतरिक redundancy के साथ अचूक, तर्क को चुनौती देने वाली speed और ऐसी features से भरे amazing boxes के रूप में advertise और बेचा जाता है जिनकी आपको पता भी नहीं थी कि आपको ज़रूरत है। नए systems डिज़ाइन करने वाले IT pros से बात करते समय, मुझे जो सबसे सामान्य design पहलू सुनने को मिलता है वह है “हम अपने अंतिम design के बारे में ज़्यादा नहीं जानते, लेकिन हम जानते हैं कि हमें SAN चाहिए।”

इस लेख के संदर्भ में, मैं SAN का उपयोग उसके सबसे सामान्य अर्थ में करता हूँ, यानी एक “block storage device” के रूप में न कि पूरे storage network को संदर्भित करने के लिए। NAS के लिए एक storage network हो सकती है लेकिन उसमें SAN block storage device बिल्कुल न हो। तो इस लेख के लिए SAN विशेष रूप से एक device के रूप में SAN को संदर्भित करता है, SAN को एक network के रूप में नहीं। SAN एक flexible शब्द है जिसका अलग-अलग समय पर अलग-अलग अर्थ होता है और यह काफी भ्रामक हो सकता है। बिना network के configure किया गया SAN DAS बन जाता है। Networked DAS SAN बन जाता है।

एक पल के लिए रुकते हैं। SAN आपका back end storage है। इसकी आवश्यकता, सभी मामलों में, आपकी architecture के अन्य पहलुओं द्वारा निर्धारित की जाएगी। यदि आपने अभी तक कई अन्य चीजें तय नहीं की हैं, तो आप बस यह नहीं जान सकते कि अंतिम design में SAN की आवश्यकता होगी या नहीं, या यहाँ तक कि उपयोगी भी होगा। लाल झंडे। हर जगह लाल झंडे। एक Roman रथ दौड़ की कल्पना करें जिसमें घोड़े रथों को धकेलते हैं (अगर आप समझ रहे हैं तो)।

यह स्पष्ट है कि SAN लागू करने की ललक इतनी तीव्र है कि अक्सर पूरी परियोजनाएं बिना किसी उद्देश्य के तैयार की जाती हैं, केवल SAN की खरीद को justify करने के लिए। किसी भी परियोजना की तरह, पहला प्रश्न जो पूछना चाहिए वह है “वह business ज़रूरत क्या है जिसे हम पूरा करने की कोशिश कर रहे हैं?” और वहाँ से काम करें, न कि “हम SAN खरीदना चाहते हैं, इसे कहाँ उपयोग करें?” SAN जटिल हैं, और जटिलता के साथ नाज़ुकपन आता है। अक्सर SAN की लागत अधिक होती है। लेकिन SAN का सबसे डरावना पहलू उनके बारे में उद्योग में गहन ज्ञान की व्यापक कमी है। SAN भारी तकनीकी और business जोखिम पैदा करते हैं जिन्हें उनके उपयोग को justify करने के लिए दूर करना होगा। SAN बिना किसी संदेह के बहुत रोमांचक और काफी उपयोगी हैं, लेकिन यह शायद ही कभी इसे चाहने के लिए पर्याप्त कारण होता है।

हम SAN को “अंतिम उपाय का storage” कहते हैं। इसका मतलब यह है कि storage के प्रकारों को चुनते समय, आप उम्मीद करते हैं कि आप किसी अन्य विकल्प जैसे local drives, DAS (Direct Attach Storage) या NAS (Network Attached Storage) का उपयोग कर सकते हैं, न कि SAN का। अधिकांश समय, अन्य विकल्प बेहतरीन काम करते हैं। लेकिन ऐसे समय होते हैं जब business की ज़रूरतें ऐसी requirements पैदा करती हैं जो केवल SAN से ही उचित रूप से पूरी की जा सकती हैं। जब ऐसा होता है, हमारे पास कोई विकल्प नहीं होता और SAN का उपयोग करना पड़ता है। लेकिन सामान्यतः इसे सरल और आम तौर पर कम खर्चीले या कम जोखिम वाले विकल्पों के पक्ष में टाला जा सकता है।

मुझे लगता है कि SAN लागू करने की सोच रखने वाले अधिकांश लोग कई गलतफहमियों के तहत ऐसा कर रहे हैं।

पहली यह है कि SAN, अपनी प्रकृति से, अत्यधिक विश्वसनीय हैं। जबकि निश्चित रूप से कई SAN vendors और specific SAN products हैं जो अत्यधिक विश्वसनीय हैं, यही बात किसी भी IT product के बारे में कही जा सकती है। उच्च-end SANs की price range के high-end servers उतने ही विश्वसनीय हैं जितने SANs। चूँकि SANs normal servers के समान hardware components से बनाए जाते हैं, उन्हें अधिक विश्वसनीय बनाने में कोई जादू नहीं है। SAN को विश्वसनीय बनाने के लिए जो कुछ भी उपयोग किया जा सकता है वह server RAS (Reliability, Availability and Serviceability) तकनीकों का trickle-down है। SAN की तरह ही NAS और DAS, साथ ही local disks, को अविश्वसनीय रूप से विश्वसनीय बनाया जा सकता है। SAN केवल block storage प्रदान करने के लिए उपयोग किए जाने वाले device को संदर्भित करता है न कि कोई अन्य कार्य करने के लिए। SAN बस एक बहुत सरल server है। SANs विश्वसनीयता की पूरी range को cover करते हैं, शीर्ष पर mainframe जैसी विश्वसनीयता से लेकर नीचे ऐसे devices तक जो कुछ और नहीं बल्कि external hard drives हैं – आपके network पर सबसे अविश्वसनीय network devices। इसलिए SAN का मतलब विश्वसनीयता होने के बजाय, यह वास्तव में कुछ विशेष मामले प्रदान करता है जहाँ यह सबसे कम विश्वसनीयता है जिसकी आप कल्पना कर सकते हैं। लेकिन, सभी व्यावहारिक उद्देश्यों के लिए, सभी servers में लगभग समान विश्वसनीयता संबंधी चिंताएं हैं। SANs विश्वसनीयता के लिए प्रतिष्ठा प्राप्त करते हैं क्योंकि अक्सर व्यवसाय अपने SANs में अत्यधिक budget लगाते हैं जो वे अपने servers में नहीं लगाते, जिससे तुलना एक अपेक्षाकृत high-end SAN और एक अपेक्षाकृत budget server के बीच होती है।

दूसरी यह है कि SAN का मतलब “बड़ा” और NAS का मतलब “छोटा” है। ऐसा कोई संबंध नहीं है। SANs और NASs दोनों लगभग किसी भी scale या quality के हो सकते हैं। दोनों पूरी range cover करते हैं और चुनी गई तकनीक से यह बिल्कुल नहीं पता चलता कि device बड़ा है या नहीं। फिर से, जैसा ऊपर बताया, SAN वास्तव में तकनीकी रूप से NAS solution से “छोटा” हो सकता है अपनी संभावित सरलता के कारण, लेकिन यह एक specialty case है और ज़्यादातर केवल theoretical है, हालाँकि बाज़ार में इस category के SAN products हैं, उन्हें उपयोग में बहुत कम देखा जाता है।

तीसरी यह है कि SAN और NAS chassis के अंदर नाटकीय रूप से अलग हैं। यह निश्चित रूप से ऐसा नहीं है क्योंकि आज अधिकांश SAN और NAS devices को “unified storage” कहा जाता है, जिसका अर्थ है एक storage appliance जो एक साथ SAN और NAS दोनों के रूप में कार्य करता है। यह highlight करता है कि दोनों के बीच मुख्य अंतर backend technology, hardware, size या विश्वसनीयता में नहीं है, बल्कि defining difference storage transfer करने के लिए उपयोग किए जाने वाले protocols में है। SANs block storage हैं जो network पर raw block devices को expose करते हैं, fibre channel, iSCSI, SAS, ZSAN, ATA over Ethernet (AoE) या Fibre Channel over Ethernet (FCoE) जैसे protocols का उपयोग करते हुए। NAS, दूसरी ओर, एक network file system का उपयोग करता है और network पर files को application layer protocols जैसे NFS, SMB, AFP, HTTP और FTP के माध्यम से expose करता है जो TCP/IP पर चलते हैं।

चौथी यह है कि SAN स्वाभाविक रूप से एक file sharing तकनीक है। यह NAS है। SAN बस आपके block storage (hard disk subsystem) को लेकर उसे network पर remotely उपलब्ध कराना है। Networks की प्रकृति यह बताती है कि हम उस storage को एक साथ कई devices से attach कर सकते हैं और वास्तव में, physically, हम कर सकते हैं। जैसे हम कभी physically multiple controllers को एक SCSI ribbon cable के विपरीत सिरों पर attach कर सकते थे जिसके बीच में hard drives लटकी होती थीं। यह, सामान्य परिस्थितियों में, drives पर सारा data नष्ट कर देगा क्योंकि controllers, जो एक दूसरे के बारे में कुछ नहीं जानते, एक दूसरे के data को overwrite कर देते हैं जिससे तुरंत corruption होती है। इसके लिए special clustered filesystems और उनके drivers में mechanisms उपलब्ध हैं, लेकिन इसके लिए special knowledge और समझ की ज़रूरत है जो SAN प्राप्त करने वाले कई लोगों की उस purpose के लिए awareness से कहीं अधिक technical है जिसे वे SAN का मुख्य उद्देश्य मानते हैं – एक ऐसी disaster जो इतनी सामान्य है कि मैं शायद लगभग हर हफ्ते किसी ऐसे व्यक्ति से बात करता हूँ जिसने यही किया है। यह कि SAN उस बहुत ही use case को जोखिम में डालता है जिसके लिए अधिकांश लोग मानते हैं कि यह designed है और न केवल लगभग जादुई सुरक्षा प्रदान करने में विफल रहता है बल्कि, इसके विपरीत, data loss का कारण ही बनता है, यह उस जोखिम के स्तर को उजागर करता है जो गलत समझी गई storage तकनीक को लागू करने पर होता है।

पाँचवीं यह है कि SAN तेज़ हैं। SAN तेज़ हो सकते हैं; वे भयानक रूप से धीमे भी हो सकते हैं। SAN तकनीक के उपयोग से अपने आप कोई intrinsic speed boost नहीं होती। SAN के लिए उस network की inherent bottlenecks को overcome करना वास्तव में काफी मुश्किल है जिस पर वे बैठे हैं। जैसे कुछ अन्य storage options जैसे DAS, SAN की सभी समान तकनीकों का उपयोग करते हैं लेकिन actual network की bottleneck और latency की कमी होती है, एक equivalent DAS भी अपने SAN complement से थोड़ा तेज़ होगा। SANs generally एक hardware-identical NAS equivalent से थोड़े तेज़ होते हैं, लेकिन यह भी guaranteed नहीं है। SAN और NAS अलग-अलग तरह से व्यवहार करते हैं और अलग-अलग use cases में कोई भी बेहतर प्रदर्शन कर सकता है। Performance की ज़रूरतों के आधार पर SAN को शायद ही कभी समाधान के रूप में चुना जाएगा।

छठी यह है कि SAN होने से storage choices से जुड़ी inherent problems अब लागू नहीं होतीं। एक अच्छा उदाहरण RAID 5 का उपयोग है। एक server में ऐसा करना bad practice माना जाएगा, लेकिन SAN के साथ काम करते समय (जो सिद्धांत रूप में एक standalone server से कहीं अधिक critical है) अक्सर careful storage subsystem planning को इस विश्वास के आधार पर नज़रअंदाज़ किया जाता है कि SAN होने की वजह से उन issues को somehow ठीक कर दिया गया है या वे लागू नहीं होतीं। यह सच है कि कुछ high-end SANs में कुछ risk mitigation features होती हैं जो elsewhere मिलना unlikely है, लेकिन ये rare हैं और exclusively बहुत high-end units तक ही सीमित हैं जहाँ fragile designs पहले से ही uncommon होंगे। एक dangerous लेकिन बहुत common practice यह है कि physical server के लिए storage planning करते समय great care और consideration किया जाता है लेकिन SAN का उपयोग करते समय यही planning और oversight अक्सर इस assumption के आधार पर skip कर दी जाती है कि SAN इसे internally handle कर लेता है या यह simply अब ज़रूरी नहीं है।

SAN के बारे में कई गलतफहमियों को दूर करने के बाद, कोई सोच सकता है कि क्या SANs कभी उपयुक्त हैं। वे निश्चित रूप से बहुत महत्वपूर्ण हैं और सही तरीके से उपयोग होने पर अविश्वसनीय रूप से मूल्यवान हैं। SANs की सबसे मज़बूत points consolidation और विशेष प्रकार की shared storage से आती हैं।

Consolidation ऐतिहासिक रूप से customers को SAN solutions की ओर ले जाने वाला driver था। SAN हमें कई filesystems को एक single disk array में combine करने की अनुमति देता है जिससे storage resources का बहुत अधिक efficient उपयोग संभव होता है। चूँकि SAN block level पर है, यह किसी भी समय ऐसा कर सकता है जब एक traditional, local disk subsystem employ किया जा सकता है। कई servers में, और यहाँ तक कि कई desktops में, growth, planning और disk capacity granularity की ज़रूरतों के कारण storage space बर्बाद हो जाती है। यदि हमारे पास बीस servers हैं, प्रत्येक 300GB drive arrays के साथ लेकिन प्रत्येक केवल 80GB capacity का उपयोग कर रहा है, तो हमारे पास बड़ी बर्बादी है। SAN के साथ हम केवल 1.6TB plus overhead के लिए आवश्यक थोड़ी मात्रा में consolidate कर सकते हैं और physical disks पर बहुत कम खर्च कर सकते हैं।

एक बार जब हम storage को consolidate करना शुरू करते हैं तो हम advanced consolidation opportunities की तलाश करने लगते हैं। कई server filesystems को एक single SAN पर consolidate करने के बाद हमें मौका मिलता है, यदि हमारा SAN implementation इसे support करे, तो उस data को deduplicate और compress करने का, जो कई मामलों में जैसे server filesystems में, potentially significant utilization reduction result कर सकता है। तो हमारे उदाहरण में 1.6TB वास्तव में केवल 800GB या उससे कम हो सकता है। अचानक हमारे consolidation numbers बेहतर और बेहतर होते जा रहे हैं।

Consolidation को efficiently leverage करने के लिए scale ज़रूरी है और यहाँ SANs वास्तव में shine करते हैं – जब capacity में और, अधिक महत्वपूर्ण रूप से, attaching nodes की संख्या में scale बहुत बड़ी हो जाती है। SANs large scale storage consolidation के लिए सबसे उपयुक्त हैं। यही उनका sweet spot है और यही उन्हें large enterprises में लगभग ubiquitous और छोटे enterprises में बहुत rare बनाता है।

SANs कुछ प्रकार की clustering और shared storage के लिए भी बहुत महत्वपूर्ण हैं जिनके लिए single shared filesystem access की आवश्यकता होती है। यह वास्तव में एक विशेष परिस्थिति के बाहर काफी rare need है – databases। अधिकांश applications उन्हें दिए गए किसी भी प्रकार के storage का उपयोग करके खुश हैं, लेकिन databases को अक्सर अपने data को सबसे प्रभावी ढंग से manipulate करने के लिए low level block access की आवश्यकता होती है। इस वजह से उन्हें NAS या file servers पर शायद ही कभी उपयोग किया जा सकता है, या प्रभावी ढंग से उपयोग किया जा सकता है। Database clusters के लिए high availability storage environments प्रदान करना SAN storage का एक प्रमुख use case रहा है।

इन दो primary use cases के अलावा, जो SAN installations की विशाल बहुमत को justify करते हैं, SAN storage flexibility के उच्च स्तर भी प्रदान करता है जिससे large environment में बिना physical moves या complicated procurement और provisioning की ज़रूरत के storage को move, grow और modify करना potentially बहुत simple हो जाता है। फिर से, consolidation की तरह, यह large scale का artifact है।

बहुत large environments में, SAN का उपयोग storage और system engineering teams के बीच demarcation point प्रदान करने के लिए भी किया जा सकता है, जिससे network layer पर handoff हो सके, generally fibre channel या iSCSI पर। Duties का यह clear separation उन companies में teams को highly segregate करने की अनुमति देने में critical हो सकता है जो highly discrete storage, network और systems teams चाहती हैं। यह storage team को केवल storage पर focus करने और systems team को केवल systems पर focus करने की अनुमति देता है, बिना दूसरे team के implementations की knowledge की ज़रूरत के।

काफी समय तक SANs ने storage performance बेहतर करने के एक सुविधाजनक साधन के रूप में खुद को प्रस्तुत किया। यह SAN का intrinsic component नहीं है बल्कि consolidation के लिए उनके सामान्य उपयोग का outgrowth है। Virtualization की तरह जब consolidation के लिए उपयोग किया जाता है, shared SANs को available spindles का बेहतर utilization, centralized caches और equivalent storage की तुलना में बड़े hardware का natural advantage होगा। Shared CPU resources की तरह, जब SAN multiple clients से requests नहीं प्राप्त कर रहा होता है तो उसके पास एक single client के requests को service करने की अपनी सारी capacity dedicate करने की क्षमता होती है, जिससे average performance experience potentially बहुत अधिक हो सकता है।

Performance के लिए SAN का उपयोग तेजी से favor से बाहर हो रहा है, हालाँकि, SSD storage के बहुत common होने की वजह से। चूँकि अविश्वसनीय रूप से कम latency और high IOPS performance वाले SSDs की कीमत उस point तक गिर रही है जहाँ उन्हें standalone servers में local cache के रूप में या potentially mainline storage के रूप में भी जोड़ा जा रहा है, SANs की networking की bottleneck एक बड़ा और बड़ा factor बन रही है जिससे SAN के consolidation benefits के लिए local SSDs के performance benefits को offset करना increasingly difficult होता जा रहा है। SSDs shared storage market के लिए potentially बहुत disruptive हैं क्योंकि वे performance advantage को local storage की ओर वापस लाते हैं – storage architecture design के ebb और flow में बस नवीनतम।

SAN usage का सबसे महत्वपूर्ण पहलू याद रखना है कि SAN storage planning में default starting point नहीं होना चाहिए। यह कई technology choices में से एक है और अक्सर ऐसा नहीं होता जो intended के अनुसार bill fit करे या ऐसा करे लेकिन unnecessarily high price point पर, monetary या complexity terms में। Business goals और needs को define करके शुरू करें। SAN को चुनें जब यह उन needs को सबसे प्रभावी ढंग से solve करे, लेकिन open mind रखें और environment की overall storage needs पर विचार करें।