تأسیس ۲۰۰۸ · نسخهٔ دیجیتال · 19 ژوئن 2026

SMB IT Journal

منبع فناوری اطلاعات برای کسب‌وکارهای کوچک

فارسی
ذخیره‌سازی

چه زمانی باید SAN را در نظر بگیرید؟

به نظر می‌رسد همه می‌خواهند با اشتیاق فراوان اقدام به خرید SAN کنند. SANها، صادقانه بگویم، بسیار جذاب هستند. آنها از جمله تجهیزات سخت‌افزاری بزرگ و هیجان‌انگیزی هستند که اکثر متخصصان فناوری اطلاعات فرصت دارند در محل کار خود داشته باشند. اغلب تمایل به داشتن یک SAN مسئله‌ای است که از «همگام بودن با دیگران» ناشی می‌شود، چرا که استفاده از SAN به نوعی نماد اعتبار شده – یکی از آخرین نمادهای فناوری اطلاعات شرکت‌های بزرگ که تنها در اتاق سرور اختصاصی یافت می‌شود و هرگز در خانه کسی نیست (خب، تقریباً هرگز). SANها به شدت تبلیغ می‌شوند و به‌عنوان جعبه‌هایی شگفت‌انگیز با افزونگی داخلی که آنها را شکست‌ناپذیر می‌کند، سرعتی که منطق را به چالش می‌کشد و ویژگی‌هایی که هرگز نمی‌دانستید به آنها نیاز دارید، فروخته می‌شوند. وقتی با متخصصان فناوری اطلاعات در حال طراحی سیستم‌های جدید صحبت می‌کنم، یکی از رایج‌ترین جنبه‌های طراحی که می‌شنوم این است: «ما طراحی نهایی را نمی‌دانیم، اما می‌دانیم که به یک SAN نیاز داریم.»

در این مقاله، SAN را در متداول‌ترین معنایش به کار می‌برم، یعنی «دستگاه ذخیره‌سازی بلوکی» و نه اشاره به کل شبکه ذخیره‌سازی. یک شبکه ذخیره‌سازی می‌تواند برای NAS وجود داشته باشد بدون اینکه از دستگاه ذخیره‌سازی بلوکی SAN استفاده کند. پس در این مقاله SAN منحصراً به SAN به‌عنوان یک دستگاه اشاره دارد، نه SAN به‌عنوان یک شبکه. SAN اصطلاحی مبهم است که در زمان‌های مختلف معانی مختلفی دارد و می‌تواند بسیار گیج‌کننده باشد. یک SAN پیکربندی‌شده بدون شبکه به DAS تبدیل می‌شود. DAS که به شبکه متصل شود SAN می‌شود.

بیایید یک لحظه مکث کنیم. SAN ذخیره‌سازی back-end شما است. نیاز به آن در همه موارد توسط سایر جنبه‌های معماری شما تعیین می‌شود. اگر هنوز تصمیم‌های زیادی نگرفته‌اید، ساده‌لوحانه است که بدانید آیا SAN مورد نیاز خواهد بود یا حتی در طراحی نهایی مفید خواهد بود. پرچم‌های قرمز. پرچم‌های قرمز همه جا. تصور کنید مسابقه ارابه‌رانی رومی که در آن اسب‌ها ارابه‌ها را هل می‌دهند (اگر منظورم را می‌دانید).

روشن است که انگیزه برای پیاده‌سازی SAN آنقدر قوی است که اغلب کل پروژه‌ها با هدفی اندک طراحی می‌شوند که به نظر می‌رسد تنها منظور آنها توجیه خرید SAN است. مانند هر پروژه‌ای، اولین سوالی که باید پرسید این است: «چه نیاز کسب‌وکاری را می‌خواهیم برآورده کنیم؟» و از آنجا شروع کنید، نه از «می‌خواهیم SAN بخریم، کجا می‌توانیم از آن استفاده کنیم؟» SANها پیچیده هستند و با پیچیدگی شکنندگی می‌آید. اغلب SANها هزینه بالایی دارند. اما ترسناک‌ترین جنبه SAN فقدان گسترده دانش عمیق صنعتی درباره آنها است. SANها ریسک‌های فنی و تجاری عظیمی دارند که باید بر آنها غلبه کرد تا استفاده از آنها توجیه داشته باشد. SANها بدون شک بسیار هیجان‌انگیز و کاملاً مفید هستند، اما این به‌ندرت کافی است تا تمایل به داشتن یکی را توجیه کند.

ما از SANها به‌عنوان «ذخیره‌سازی آخرین چاره» یاد می‌کنیم. این به این معناست که وقتی نوع ذخیره‌سازی را انتخاب می‌کنید، امیدوارید بتوانید از هر گزینه دیگری مانند درایوهای محلی، DAS (ذخیره‌سازی متصل مستقیم) یا NAS (ذخیره‌سازی متصل به شبکه) استفاده کنید تا SAN. در اکثر مواقع، سایر گزینه‌ها عالی کار می‌کنند. اما گاهی نیازهای کسب‌وکار الزاماتی را مطرح می‌کنند که به‌طور منطقی تنها با SAN قابل تأمین هستند. در آن صورت، چاره‌ای نداریم و باید از SAN استفاده کنیم. اما به‌طور کلی می‌توان از آن اجتناب کرد و به‌جای آن از گزینه‌های ساده‌تر و معمولاً کم‌هزینه‌تر یا کم‌ریسک‌تر استفاده کرد.

می‌یابم که اکثر افرادی که می‌خواهند SAN پیاده‌سازی کنند این کار را تحت تأثیر تعدادی سوءتفاهم انجام می‌دهند.

اول اینکه SANها ذاتاً بسیار قابل‌اطمینان هستند. در حالی که قطعاً فروشندگان SAN و محصولات SAN خاصی وجود دارند که به‌طور شگفت‌انگیزی قابل‌اطمینان هستند، همین را می‌توان درباره هر محصول فناوری اطلاعات گفت. سرورهای high-end در محدوده قیمت SANهای high-end به همان اندازه قابل‌اطمینان هستند. از آنجا که SANها از همان اجزای سخت‌افزاری سرورهای معمولی ساخته می‌شوند، هیچ جادویی برای قابل‌اطمینان‌تر کردن آنها وجود ندارد. هر چیزی که می‌تواند برای قابل‌اطمینان کردن SAN به کار رود، نتیجه‌ای از فناوری‌های RAS (قابلیت اطمینان، دسترس‌پذیری و سرویس‌پذیری) سرور است. درست مانند SAN، NAS و DAS و همچنین دیسک‌های محلی می‌توانند به‌طور باورنکردنی قابل‌اطمینان ساخته شوند. SAN تنها به دستگاهی اشاره می‌کند که برای سرویس‌دهی به ذخیره‌سازی بلوکی به جای انجام کار دیگری استفاده می‌شود. یک SAN صرفاً یک سرور بسیار ساده است. SANها طیف کاملی از قابلیت اطمینان را پوشش می‌دهند، از قابلیت اطمینان مین‌فریم‌مانند در بالاترین سطح تا دستگاه‌هایی که چیزی بیش از هارد دیسک‌های خارجی نیستند – کم‌قابل‌اطمینان‌ترین دستگاه‌های شبکه در شبکه شما – در پایین‌ترین سطح. پس به جای اینکه SAN به معنای قابلیت اطمینان باشد، در واقع چند مورد خاص از پایین‌ترین قابلیت اطمینان ممکن را ارائه می‌دهد. اما از نظر عملی، همه سرورها نگرانی‌های قابلیت اطمینان تقریباً یکسانی دارند. SANها به دلیل قابلیت اطمینان شهرت پیدا می‌کنند چون اغلب کسب‌وکارها بودجه‌های هنگفتی برای SANهایشان می‌گذارند که برای سرورهایشان نمی‌گذارند، بنابراین مقایسه بین یک SAN نسبتاً high-end و یک سرور نسبتاً بودجه‌ای است.

دوم اینکه SAN به معنای «بزرگ» و NAS به معنای «کوچک» است. چنین ارتباطی وجود ندارد. هم SANها و هم NASها می‌توانند تقریباً در هر مقیاس یا کیفیتی باشند. هر دو طیف کاملی را پوشش می‌دهند و کمترین نشانه‌ای از فناوری انتخاب‌شده وجود ندارد که نشان دهد یک دستگاه بزرگ است یا خیر. دوباره، همانطور که در بالا گفته شد، SAN می‌تواند از نظر فنی «کوچک‌تر» از یک راه‌حل NAS به دلیل سادگی احتمالی‌اش باشد، اما این یک مورد تخصصی است و بیشتر نظری است، هرچند محصولات SAN در این دسته در بازار موجودند، فقط بسیار نادر است که آنها را در حال استفاده ببینید.

سوم اینکه SAN و NAS از داخل شاسی به‌طور چشمگیری متفاوتند. این قطعاً صحیح نیست چرا که اکثر دستگاه‌های SAN و NAS امروزی آنچه «unified storage» نامیده می‌شود هستند، یعنی یک دستگاه ذخیره‌سازی که به‌طور همزمان هم به‌عنوان SAN و هم NAS عمل می‌کند. این موضوع نشان می‌دهد که تفاوت کلیدی بین آن دو نه در فناوری back-end یا سخت‌افزار یا اندازه یا قابلیت اطمینان، بلکه در پروتکل‌های مورد استفاده برای انتقال ذخیره‌سازی است. SANها ذخیره‌سازی بلوکی هستند که دستگاه‌های بلوکی خام را روی شبکه با استفاده از پروتکل‌هایی مانند fibre channel، iSCSI، SAS، ZSAN، ATA over Ethernet (AoE) یا Fibre Channel over Ethernet (FCoE) در معرض دید قرار می‌دهند. NAS، از سوی دیگر، از یک سیستم فایل شبکه‌ای استفاده می‌کند و فایل‌ها را روی شبکه با استفاده از پروتکل‌های لایه کاربردی مانند NFS، SMB، AFP، HTTP و FTP که روی TCP/IP کار می‌کنند در معرض دید قرار می‌دهد.

چهارم اینکه SANها ذاتاً یک فناوری اشتراک‌گذاری فایل هستند. این NAS است. SAN صرفاً ذخیره‌سازی بلوکی شما (زیرسیستم دیسک سخت) را از راه دور روی یک شبکه در دسترس قرار می‌دهد. ماهیت شبکه‌ها نشان می‌دهد که می‌توانیم آن ذخیره‌سازی را به‌طور همزمان به چندین دستگاه متصل کنیم و از نظر فیزیکی این کار ممکن است. درست مانند زمانی که می‌توانستیم چندین کنترلر را به دو انتهای کابل ribbon SCSI با هارد درایوهایی که در وسط آویزان بودند متصل کنیم. این در شرایط عادی همه داده‌های روی درایوها را نابود خواهد کرد زیرا کنترلرها که از هم اطلاعی ندارند، داده‌های یکدیگر را بازنویسی می‌کنند و باعث خرابی تقریباً فوری می‌شوند. مکانیزم‌هایی در سیستم‌های فایل خوشه‌ای خاص و درایورهای آنها وجود دارد که این را ممکن می‌سازد، اما این نیاز به دانش و درک تخصصی دارد که بسیار فنی‌تر از چیزی است که بسیاری از افرادی که SANها را تهیه می‌کنند از نیاز به آن آگاهند، برای آنچه اغلب معتقدند هدف اصلی SAN است – یک فاجعه آنقدر رایج که تقریباً هر هفته با کسی صحبت می‌کنم که دقیقاً همین کار را کرده است. اینکه SAN دقیقاً آن کاربردی را که اکثر مردم تصور می‌کنند برای آن طراحی شده به خطر می‌اندازد و نه تنها از ارائه حفاظت جادویی مورد نظر ناکام می‌ماند، بلکه برعکس، خود عامل از دست رفتن داده می‌شود، سطح ریسکی را که فناوری ذخیره‌سازی اشتباه فهمیده‌شده به همراه می‌آورد نشان می‌دهد.

پنجم اینکه SANها سریع هستند. SANها می‌توانند سریع باشند؛ همچنین می‌توانند به‌طور وحشتناکی کُند باشند. هیچ افزایش سرعت ذاتی از استفاده از فناوری SAN به‌تنهایی وجود ندارد. در واقع برای SANها نسبتاً دشوار است که بر گلوگاه‌های ذاتی معرفی‌شده توسط شبکه‌ای که روی آن قرار دارند غلبه کنند. از آنجا که برخی گزینه‌های دیگر ذخیره‌سازی مانند DAS از همان فناوری‌های SAN استفاده می‌کنند اما فاقد گلوگاه و تأخیر شبکه واقعی هستند، یک DAS معادل نیز کمی سریع‌تر از همتای SAN خود خواهد بود. SANها به‌طور کلی کمی سریع‌تر از معادل NAS با سخت‌افزار یکسان هستند، اما حتی این هم تضمین‌شده نیست. SAN و NAS رفتار متفاوتی دارند و در موارد استفاده مختلف هر یک ممکن است عملکرد بهتری داشته باشد. SAN به‌ندرت به دلیل نیازهای عملکردی انتخاب می‌شود.

ششم اینکه با داشتن یک SAN، مشکلات ذاتی مرتبط با انتخاب‌های ذخیره‌سازی دیگر اعمال نمی‌شوند. یک مثال خوب استفاده از RAID 5 است. استفاده از آن در یک سرور عملکرد بدی محسوب می‌شود، اما وقتی با یک SAN کار می‌کنیم (که از نظر تئوری بسیار حیاتی‌تر از یک سرور مستقل است)، اغلب برنامه‌ریزی دقیق زیرسیستم ذخیره‌سازی نادیده گرفته می‌شود بر اساس این باور که SAN بودن آن مشکلات را به‌طور ذاتی حل کرده یا آنها دیگر اعمال نمی‌شوند. درست است که برخی SANهای high-end دارای برخی ویژگی‌های کاهش ریسک هستند که کمتر در جاهای دیگر یافت می‌شود، اما اینها نادر و منحصراً محدود به واحدهای بسیار high-end هستند که در آنها استفاده از طراحی‌های شکننده از قبل غیرمعمول بود. این یک عمل خطرناک اما بسیار رایج است که هنگام برنامه‌ریزی ذخیره‌سازی برای یک سرور فیزیکی دقت و توجه زیادی صرف می‌شود اما وقتی از SAN استفاده می‌شود، همان برنامه‌ریزی و نظارت اغلب نادیده گرفته می‌شود بر اساس این فرض که SAN همه آنها را به‌صورت داخلی مدیریت می‌کند یا دیگر لازم نیست.

پس از رد کردن بسیاری از سوءتفاهمات درباره SAN، ممکن است تعجب کنید که آیا SANها اصلاً مناسب هستند. البته وقتی به‌درستی استفاده شوند، بسیار مهم و ارزشمند هستند. قوی‌ترین نقاط SANها از تجمیع و انواع خاصی از ذخیره‌سازی مشترک ناشی می‌شود.

تجمیع محرک تاریخی آوردن مشتریان به راه‌حل‌های SAN بود. یک SAN به ما اجازه می‌دهد تا بسیاری از سیستم‌های فایل را در یک آرایه دیسکی واحد ترکیب کنیم که استفاده بسیار کارآمدتری از منابع ذخیره‌سازی را امکان‌پذیر می‌سازد. از آنجا که SAN در سطح بلوک است، می‌تواند این کار را هر زمانی که زیرسیستم دیسک محلی سنتی قابل استفاده باشد انجام دهد. در بسیاری از سرورها و حتی بسیاری از دسکتاپ‌ها، فضای ذخیره‌سازی به دلیل ضروریات رشد، برنامه‌ریزی و دانه‌بندی ظرفیت دیسک هدر می‌رود. اگر بیست سرور داشته باشیم که هر کدام آرایه‌های درایو 300GB داشته باشند اما هر کدام فقط از 80GB آن استفاده کنند، اتلاف زیادی داریم. با یک SAN می‌توانستیم فقط به 1.6TB به علاوه مقدار کمی لازم برای overhead تجمیع کنیم و بسیار کمتر از زمانی که هر سرور ذخیره‌سازی خود را نگه می‌داشت برای دیسک‌های فیزیکی هزینه کنیم.

هنگامی که شروع به تجمیع ذخیره‌سازی می‌کنیم، به دنبال فرصت‌های تجمیع پیشرفته می‌گردیم. با تجمیع بسیاری از سیستم‌های فایل سرور روی یک SAN واحد، اگر پیاده‌سازی SAN ما از آن پشتیبانی کند، این فرصت را داریم که آن داده‌ها را deduplicate و فشرده کنیم که در بسیاری از موارد مانند سیستم‌های فایل سرور می‌تواند به کاهش قابل‌توجهی در استفاده منجر شود. بنابراین 1.6TB در مثال بالا ممکن است در واقع فقط 800GB یا کمتر شود. ناگهان اعداد تجمیع ما بهتر و بهتر می‌شوند.

برای استفاده کارآمد از تجمیع، مقیاس لازم است و اینجاست که SANها واقعاً می‌درخشند – وقتی مقیاس در ظرفیت و مهم‌تر از آن در تعداد گره‌های متصل‌کننده بسیار بزرگ شود. SANها برای تجمیع ذخیره‌سازی در مقیاس بزرگ بیشترین مناسبت را دارند. این نقطه قوت آنها است و چیزی است که آنها را تقریباً در شرکت‌های بزرگ همه‌جا و در شرکت‌های کوچک بسیار نادر می‌کند.

SANها همچنین برای انواع خاصی از خوشه‌بندی و ذخیره‌سازی مشترک که نیازمند دسترسی به سیستم فایل مشترک واحد هستند بسیار مهم هستند. این در واقع یک نیاز نسبتاً نادر به جز در یک موقعیت خاص است – پایگاه‌های داده. اکثر برنامه‌ها خوشحال هستند که از هر نوع ذخیره‌سازی ارائه‌شده به آنها استفاده کنند، اما پایگاه‌های داده اغلب به دسترسی بلوکی پایین‌سطح نیاز دارند تا بتوانند داده‌های خود را به‌طور مؤثرتر دستکاری کنند. به همین دلیل به‌ندرت می‌توانند روی NAS یا سرورهای فایل استفاده شوند یا به‌طور مؤثر استفاده شوند. فراهم کردن محیط‌های ذخیره‌سازی با دسترس‌پذیری بالا برای خوشه‌های پایگاه داده مدت‌هاست که یک کاربرد کلیدی ذخیره‌سازی SAN بوده است.

خارج از این دو کاربرد اصلی که اکثریت قریب به اتفاق نصب‌های SAN را توجیه می‌کنند، SAN همچنین انعطاف‌پذیری بالایی در ذخیره‌سازی فراهم می‌کند و جابجایی، رشد و تغییر ذخیره‌سازی را در یک محیط بزرگ بدون نیاز به جابجایی‌های فیزیکی یا تأمین و پروویژن پیچیده بالقوه بسیار ساده می‌کند. دوباره، مانند تجمیع، این نتیجه مقیاس بزرگ است.

در محیط‌های بسیار بزرگ، استفاده از SAN همچنین می‌تواند برای ایجاد یک نقطه جداسازی بین تیم‌های مهندسی ذخیره‌سازی و سیستم‌ها استفاده شود که به آنها اجازه می‌دهد در لایه شبکه، عموماً fibre channel یا iSCSI، تحویل دهند. این جداسازی روشن وظایف می‌تواند در شرکت‌هایی که می‌خواهند تیم‌های ذخیره‌سازی، شبکه و سیستم‌های کاملاً مجزا داشته باشند بسیار حیاتی باشد. این به تیم ذخیره‌سازی اجازه می‌دهد فقط روی ذخیره‌سازی تمرکز کند و به تیم سیستم‌ها اجازه می‌دهد فقط روی سیستم‌ها تمرکز کند بدون هیچ نیازی به دانستن پیاده‌سازی‌های تیم دیگر.

برای مدت طولانی SANها همچنین خود را به‌عنوان یک وسیله مناسب برای بهبود عملکرد ذخیره‌سازی معرفی کردند. این یک جزء ذاتی SAN نیست بلکه نتیجه استفاده رایج آنها برای تجمیع است. مشابه مجازی‌سازی وقتی به‌عنوان تجمیع استفاده می‌شود، SANهای مشترک مزیت طبیعی استفاده بهتر از spindle‌های موجود، کش‌های متمرکز و سخت‌افزار بزرگ‌تر در مقابل ذخیره‌سازی معادلی را خواهند داشت که در میان بسیاری از سرورهای جداگانه پخش شده است. مانند منابع CPU مشترک، وقتی SAN درخواست‌هایی از چندین کلاینت دریافت نمی‌کند، توانایی اختصاص دادن کل ظرفیت خود به پردازش درخواست‌های یک کلاینت واحد را دارد و یک تجربه عملکرد میانگین بالقوه بسیار بالاتر از آنچه یک سرور جداگانه به‌طور مقرون‌به‌صرفه می‌تواند به‌تنهایی دست یابد ارائه می‌دهد.

با این حال، استفاده از SAN برای عملکرد به‌سرعت در حال از دست دادن محبوبیت است، زیرا ذخیره‌سازی SSD بسیار رایج شده است. با کاهش قیمت SSDها با تأخیر بسیار پایین و عملکرد IOPS بالا تا حدی که به سرورهای مستقل به‌عنوان کش محلی یا حتی به‌عنوان ذخیره‌سازی اصلی اضافه می‌شوند، گلوگاه شبکه‌سازی SAN عامل بزرگ‌تر و بزرگ‌تری می‌شود که جبران مزایای تجمیع SAN توسط مزایای عملکردی SSDهای محلی را بیش از پیش دشوار می‌کند. SSDها برای بازار ذخیره‌سازی مشترک بالقوه بسیار مخرب هستند زیرا مزیت عملکردی را به سمت ذخیره‌سازی محلی برمی‌گردانند – فقط آخرین جزر و مد در طراحی معماری ذخیره‌سازی.

مهم‌ترین جنبه استفاده از SAN که باید به خاطر سپرد این است که SAN نباید نقطه شروع پیش‌فرض در برنامه‌ریزی ذخیره‌سازی باشد. این یکی از بسیاری از انتخاب‌های فناوری است و انتخابی که اغلب به شیوه مورد نظر مناسب نیست یا اگر هم باشد اما با قیمت غیرضروری بالایی چه از نظر مالی چه از نظر پیچیدگی. با تعریف اهداف و نیازهای کسب‌وکار شروع کنید. SAN را انتخاب کنید وقتی آن نیازها را به‌طور مؤثرترین شیوه برآورده می‌کند، اما ذهن باز داشته باشید و نیازهای ذخیره‌سازی کلی محیط را در نظر بگیرید.

برچسب‌خوردهdas nas san storage

آگهی

SMB IT Journal — the IT resource for small business