از سرور و فایروال تا NAS؛ چگونه زیرساخت IT یک شرکت را اصولی طراحی کنیم؟

از سرور و فایروال تا NAS؛ چگونه زیرساخت IT یک شرکت را اصولی طراحی کنیم؟

زیرساخت فناوری اطلاعات یک شرکت فقط مجموعه‌ای از چند دستگاه جدا از هم نیست.

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

یکی از اشتباهات رایج در شرکت‌ها این است که تجهیزات IT به‌صورت مقطعی خریداری می‌شوند.

ابتدا یک سرور تهیه می‌شود.

چند ماه بعد، به دلیل افزایش حجم اطلاعات، یک NAS اضافه می‌شود.

بعد از مدتی فایروال خریداری می‌شود.

سپس یک شعبه جدید راه‌اندازی می‌شود و سازمان تازه متوجه می‌شود که تجهیزات فعلی برای ارتباط پایدار بین سایت‌ها یا رشد آینده مناسب نیستند.

مشکل اصلی در چنین پروژه‌هایی معمولاً ضعف محصول نیست.

مشکل، نبود طراحی یکپارچه است.

یک زیرساخت حرفه‌ای باید از ابتدا بر اساس نیاز واقعی کسب‌وکار، حجم داده، تعداد کاربران، نوع سرویس‌ها، سطح ریسک، رشد آینده و زمان قابل‌تحمل قطعی طراحی شود.

طراحی زیرساخت از کجا شروع می‌شود؟

طراحی زیرساخت نباید با انتخاب برند شروع شود.

سؤال اول نباید این باشد که:

«چه سروری بخریم؟»

یا:

«کدام فایروال بهتر است؟»

پرسش‌های درست قبل از انتخاب محصول مطرح می‌شوند.

تعداد کاربران فعلی چند نفر است؟

رشد کاربر در سه سال آینده چقدر خواهد بود؟

چه سرویس‌هایی داخل سازمان اجرا می‌شوند؟

آیا ماشین مجازی وجود دارد؟

حجم داده فعلی چقدر است؟

میزان رشد سالانه اطلاعات چقدر است؟

آیا شرکت دارای شعبه است؟

آیا کاربران از بیرون به شبکه متصل می‌شوند؟

در صورت توقف سرویس، کسب‌وکار چند ساعت می‌تواند ادامه فعالیت نداشته باشد؟

آخرین سؤال اهمیت زیادی دارد.

زیرساخت شرکتی که می‌تواند یک روز قطعی را تحمل کند، با زیرساخت کارخانه، مرکز درمانی یا سازمان مالی که حتی چند ساعت توقف برای آن پرهزینه است، یکسان نیست.

بنابراین معماری باید از نیاز کسب‌وکار شروع شود، نه از فهرست محصولات موجود در بازار.

سرور؛ قلب پردازش سازمان

سرور در بسیاری از سازمان‌ها مرکز اجرای سرویس‌های حیاتی است.

نرم‌افزار مالی، ERP، فایل‌سرور، دیتابیس، سرویس‌های داخلی، ماشین‌های مجازی و سیستم‌های مدیریتی ممکن است همگی روی زیرساخت سروری اجرا شوند.

با این حال، انتخاب سرور نیز اغلب بیش از حد ساده انجام می‌شود.

برای مثال، گاهی فقط تعداد Core پردازنده یا مقدار RAM بررسی می‌شود، در حالی که نوع Workload اهمیت بیشتری دارد.

یک دیتابیس پرتراکنش ممکن است به Storage سریع نیاز داشته باشد.

زیرساخت مجازی‌سازی ممکن است نیازمند RAM بالاتر باشد.

یک فایل‌سرور معمولی ممکن است بیش از پردازنده، به ظرفیت و طراحی درست ذخیره‌سازی نیاز داشته باشد.

در انتخاب سرور باید چند موضوع هم‌زمان بررسی شوند:

نوع پردازنده،

تعداد Core،

مقدار RAM،

قابلیت افزایش حافظه،

نوع RAID Controller،

تعداد Drive Bay،

نوع دیسک،

تعداد Power Supply،

نوع کارت شبکه،

و مسیر توسعه آینده.

در زیرساخت حرفه‌ای، سرور فقط برای امروز خریداری نمی‌شود.

اگر سازمان احتمال می‌دهد طی چند سال آینده تعداد ماشین‌های مجازی، کاربران یا حجم دیتابیس افزایش پیدا کند، باید امکان ارتقا از ابتدا بررسی شود.

خرید سیستمی که در روز اول کاملاً پر شده است، معمولاً تصمیم خوبی نیست.

آیا هر شرکتی به چند سرور نیاز دارد؟

پاسخ کوتاه این است: نه همیشه.

اما پاسخ حرفه‌ای‌تر به سطح اهمیت سرویس‌ها بستگی دارد.

یک شرکت کوچک ممکن است بتواند چند سرویس خود را روی یک سرور اجرا کند.

اما در سازمانی که توقف سرویس هزینه زیادی دارد، وابستگی کامل به یک سرور می‌تواند ریسک ایجاد کند.

در چنین محیط‌هایی ممکن است استفاده از Virtualization، Cluster، سرور جایگزین یا حداقل برنامه بازیابی سریع منطقی باشد.

مهم این است که تصمیم بر اساس واقعیت کسب‌وکار گرفته شود.

گاهی Overdesign نیز به اندازه طراحی ضعیف مشکل‌ساز است.

یک شرکت کوچک ممکن است هزینه زیادی برای معماری پیچیده‌ای بپردازد که هیچ نیاز واقعی به آن ندارد.

از طرف دیگر، یک مجموعه بزرگ ممکن است برای صرفه‌جویی اولیه از طراحی افزونه صرف‌نظر کند و در روز قطعی، هزینه بسیار بیشتری متحمل شود.

نقش فایروال در معماری مدرن

فایروال امروز فقط یک دستگاه برای باز و بسته کردن Port نیست.

در شبکه‌های سازمانی، فایروال می‌تواند در کنترل دسترسی، IPS، Application Control، Web Filtering، VPN، ارتباط شعب، کنترل تهدید و Segment بندی شبکه نقش داشته باشد.

اما انتخاب فایروال باید با واقعیت شبکه هماهنگ باشد.

برای انتخاب مدل مناسب باید مواردی مانند این‌ها بررسی شوند:

تعداد کاربران هم‌زمان،

پهنای باند اینترنت،

تعداد ارتباطات هم‌زمان،

VPN Site-to-Site،

کاربران Remote Access،

SSL Inspection،

سرویس‌های Published،

تعداد شعب،

و قابلیت‌های امنیتی فعال.

یکی از اشتباهات رایج این است که سازمان فقط Firewall Throughput را می‌بیند.

عددهای تبلیغاتی بالا ممکن است جذاب باشند، اما ظرفیت واقعی در شرایطی که چند سرویس امنیتی هم‌زمان فعال هستند اهمیت بیشتری دارد.

همچنین باید برای رشد آینده ظرفیت در نظر گرفته شود.

اگر شرکت امروز ۷۰ کاربر دارد و برنامه توسعه تا ۱۵۰ کاربر در دو سال آینده وجود دارد، خرید بر اساس نیاز فعلی ممکن است تصمیم کوتاه‌مدتی باشد.

Segment بندی شبکه چرا اهمیت دارد؟

در بسیاری از شرکت‌ها، همه دستگاه‌ها داخل یک شبکه بزرگ قرار دارند.

کامپیوتر کاربران، سرورها، دوربین‌ها، تجهیزات VoIP، پرینترها و سیستم‌های مدیریتی همگی می‌توانند با یکدیگر ارتباط داشته باشند.

این معماری ساده است، اما در بسیاری از محیط‌ها امن نیست.

Segment بندی شبکه به معنی تقسیم زیرساخت به بخش‌های منطقی است.

برای مثال:

شبکه کاربران،

شبکه سرورها،

شبکه دوربین‌ها،

شبکه مدیریت،

شبکه VoIP،

و شبکه Backup.

این تفکیک باعث می‌شود دسترسی‌ها کنترل‌شده‌تر شوند و در صورت انتشار بدافزار یا نفوذ، دامنه آسیب کاهش یابد.

اما Segment بندی فقط ساختن VLAN نیست.

قوانین ارتباط بین VLANها باید به‌درستی طراحی شوند.

برای مثال، کاربر بخش فروش ممکن است نیاز داشته باشد به ERP دسترسی پیدا کند، اما نیازی ندارد مستقیم به NAS بکاپ یا شبکه مدیریت تجهیزات دسترسی داشته باشد.

معماری خوب باید اصل حداقل دسترسی را در شبکه اجرا کند.

NAS فقط یک فضای اشتراک فایل نیست

در بسیاری از سازمان‌ها، NAS هنوز فقط به‌عنوان یک فایل‌سرور ساده دیده می‌شود.

در حالی که NAS حرفه‌ای می‌تواند نقش‌های مهم‌تری داشته باشد.

ذخیره فایل،

بکاپ سرورها،

Snapshot،

Replication،

آرشیو،

ذخیره‌سازی ماشین‌های مجازی،

و بازیابی سریع از جمله کاربردهای رایج هستند.

با این حال، انتخاب NAS نیز نیازمند طراحی است.

تعداد Bay،

نوع RAID،

نوع هارد،

نوع فایل‌سیستم،

مقدار RAM،

سرعت شبکه،

پشتیبانی از 10GbE یا بالاتر،

Snapshot Policy،

و قابلیت توسعه همگی باید بررسی شوند.

فرض کنید شرکتی امروز ۲۰ ترابایت داده دارد.

اگر فقط بر اساس همین عدد NAS خریداری شود، ممکن است ظرفیت واقعی به دلیل RAID کمتر باشد.

بعد از اضافه شدن Snapshot و چند نسخه Backup، فضای بیشتری مصرف می‌شود.

با رشد سالانه داده، سیستم ممکن است خیلی زود به سقف ظرفیت برسد.

به همین دلیل، ظرفیت طراحی‌شده باید با ظرفیت فعلی تفاوت داشته باشد.

RAID چه کاری انجام می‌دهد و چه کاری انجام نمی‌دهد؟

یکی از اشتباهات رایج این است که سازمان تصور می‌کند RAID به معنی بکاپ است.

RAID می‌تواند در برابر خرابی یک یا چند دیسک، بسته به نوع طراحی، مقاومت ایجاد کند.

اما RAID از حذف اشتباه فایل جلوگیری نمی‌کند.

اگر باج‌افزار داده را رمزگذاری کند، فایل رمزگذاری‌شده روی تمام دیسک‌های آرایه نوشته می‌شود.

اگر کاربر اطلاعات را حذف کند، RAID نسخه قبلی را برنمی‌گرداند.

اگر سیستم دچار آسیب جدی شود، داشتن RAID به‌تنهایی کافی نیست.

بنابراین NAS باید بخشی از معماری Backup و Recovery باشد، نه جایگزین آن.

ارتباط بین سرور، فایروال و NAS

یکی از نقاطی که تفاوت میان خرید محصول و طراحی معماری را نشان می‌دهد، ارتباط بین این سه بخش است.

برای مثال، فرض کنیم شرکت یک سرور مجازی‌سازی دارد.

ماشین‌های مجازی باید Backup شوند.

NAS برای نگهداری بکاپ انتخاب شده است.

فایروال نیز شبکه را کنترل می‌کند.

اگر این سه بخش بدون طراحی مشترک اجرا شوند، ممکن است مشکلاتی ایجاد شود.

شبکه Backup با ترافیک کاربران مشترک باشد و هنگام بکاپ شبانه گلوگاه ایجاد شود.

NAS با همان Accountهای مدیریتی Domain کنترل شود.

تمام VLANها به NAS دسترسی داشته باشند.

Replication به شعبه دوم از اینترنت عمومی و بدون طراحی مناسب انجام شود.

فایروال برای حجم ترافیک VPN بین سایت‌ها ظرفیت کافی نداشته باشد.

این‌ها نمونه‌هایی هستند که نشان می‌دهند محصول خوب بدون معماری درست الزاماً نتیجه خوبی ایجاد نمی‌کند.

برای طراحی و تأمین تجهیزات زیرساخت سازمانی بهتر است انتخاب سرور، فایروال، NAS و تجهیزات شبکه بر اساس یک سناریوی واحد انجام شود؛ زیرا تغییر در هر بخش می‌تواند نیاز بخش‌های دیگر را نیز تغییر دهد.

شبکه داخلی؛ بخشی که معمولاً دست‌کم گرفته می‌شود

گاهی شرکت هزینه زیادی برای سرور و ذخیره‌ساز می‌کند، اما شبکه داخلی همچنان محدودیت اصلی باقی می‌ماند.

برای مثال، NAS دارای پورت 10GbE است، اما سوئیچ شبکه فقط 1GbE ارائه می‌دهد.

یا سرور و ذخیره‌ساز به سوئیچی متصل هستند که Backplane یا ظرفیت Switching مناسب بار واقعی ندارد.

در چنین شرایطی، گران‌ترین Storage نیز نمی‌تواند سرعت مورد انتظار را ارائه دهد.

در طراحی شبکه باید این موارد بررسی شوند:

سرعت Access Portها،

Uplinkها،

ارتباط بین سوئیچ‌ها،

ظرفیت Switching،

PoE Budget،

Redundancy،

تعداد VLANها،

و رشد آینده.

در شبکه‌های بزرگ‌تر، طراحی Core، Distribution و Access نیز اهمیت پیدا می‌کند.

اما باز هم باید متناسب طراحی کرد.

هر شرکتی به پیچیده‌ترین معماری نیاز ندارد.

طراحی Backup؛ بخش فراموش‌شده معماری

بکاپ باید از ابتدا جزو طراحی زیرساخت باشد، نه مرحله آخر پروژه.

برای طراحی Backup باید مشخص شود:

از چه سرویس‌هایی بکاپ گرفته می‌شود؟

هر چند وقت یک بار؟

چند نسخه نگهداری می‌شود؟

Backup Window چقدر است؟

Restore Window چقدر است؟

آیا نسخه Offsite وجود دارد؟

آیا Snapshot استفاده می‌شود؟

چه کسی اجازه حذف بکاپ دارد؟

آخرین تست Restore چه زمانی انجام شده است؟

یکی از مشکلات رایج این است که سازمان Backup Job موفق دارد، اما هیچ‌وقت بازیابی واقعی را تست نکرده است.

در روز بحران، ممکن است مشخص شود Restore بسیار کند است یا نسخه‌ها ناقص هستند.

بنابراین تست Restore باید جزو عملیات دوره‌ای باشد.

ارتباط شعب چگونه طراحی شود؟

سازمانی که چند شعبه دارد، چالش‌های بیشتری دارد.

باید مشخص شود ارتباط بین شعب به چه شکلی انجام می‌شود.

VPN سنتی،

SD-WAN،

لینک اختصاصی،

یا ترکیبی از این روش‌ها.

همچنین باید مشخص شود سرویس‌ها متمرکز هستند یا بخشی از سرویس در شعب قرار دارد.

اگر تمام شعب به دیتاسنتر مرکزی وابسته باشند، قطع ارتباط می‌تواند عملیات آن‌ها را متوقف کند.

در این شرایط ممکن است مسیر اینترنت جایگزین، Failover یا سرویس‌های محلی اهمیت پیدا کنند.

فایروال و تجهیزات WAN باید با این معماری هماهنگ انتخاب شوند.

مجازی‌سازی چه تغییری ایجاد می‌کند؟

Virtualization می‌تواند بهره‌وری زیرساخت را افزایش دهد.

چند سرویس می‌توانند روی یک یا چند Host اجرا شوند.

مدیریت منابع ساده‌تر می‌شود.

Backup و Migration نیز در بسیاری از سناریوها انعطاف‌پذیرتر می‌شوند.

اما مجازی‌سازی، نیاز به طراحی را از بین نمی‌برد.

برعکس، گاهی اهمیت Storage و Network بیشتر می‌شود.

اگر چند ماشین مجازی مهم روی یک Storage قرار دارند، خرابی Storage می‌تواند چند سرویس را هم‌زمان متوقف کند.

اگر Backup مناسب نباشد، حادثه روی یک Host ممکن است اثر گسترده‌ای داشته باشد.

در محیط‌های مجازی‌سازی باید پردازنده، RAM، Network، Storage IOPS و Backup به‌صورت هم‌زمان بررسی شوند.

امنیت Endpoint در کنار فایروال

فایروال مرزی بخشی از معماری امنیت است.

اما حملات می‌توانند از Endpoint وارد شوند.

لپ‌تاپ آلوده، حساب سرقت‌شده، فایل مخرب یا نرم‌افزار آسیب‌پذیر می‌تواند مسیر حمله باشد.

به همین دلیل، Endpoint Protection، Patch Management، MFA، کنترل دسترسی و آموزش کاربر نیز اهمیت دارند.

معماری حرفه‌ای نباید تصور کند خرید فایروال تمام مشکل امنیت را حل می‌کند.

امنیت یک لایه نیست.

هزینه Downtime باید وارد طراحی شود

یکی از بهترین روش‌ها برای تصمیم‌گیری در مورد بودجه زیرساخت، محاسبه تقریبی هزینه توقف سرویس است.

اگر سیستم مالی شرکت شش ساعت متوقف شود، چه اتفاقی می‌افتد؟

اگر فایل‌سرور یک روز در دسترس نباشد، چند کاربر متوقف می‌شوند؟

اگر ارتباط شعب قطع شود، عملیات فروش یا تولید چه تأثیری می‌گیرد؟

پاسخ این پرسش‌ها کمک می‌کند مشخص شود کجا Redundancy لازم است.

همچنین مشخص می‌شود برای کدام سرویس‌ها باید Restore سریع‌تری طراحی شود.

در زیرساخت حرفه‌ای، همه سرویس‌ها الزاماً یک سطح اهمیت ندارند.

می‌توان سرویس‌ها را اولویت‌بندی کرد.

سرویس‌های حیاتی باید زودتر بازیابی شوند.

سرویس‌های آرشیوی می‌توانند زمان بازیابی بیشتری داشته باشند.

رشد سه‌ساله را جدی بگیرید

یکی از اصول مهم طراحی زیرساخت این است که فقط وضعیت امروز دیده نشود.

تعداد کاربران ممکن است افزایش پیدا کند.

حجم داده رشد می‌کند.

سرویس‌های جدید اضافه می‌شوند.

ممکن است شعبه جدید راه‌اندازی شود.

تعداد دوربین‌ها یا کاربران VPN بیشتر شود.

اگر تمام تجهیزات فقط برای نیاز امروز خریداری شوند، سازمان زودتر از انتظار مجبور به تعویض می‌شود.

البته این به معنی خرید بیش‌ازحد بزرگ نیست.

پیش‌بینی باید واقع‌بینانه باشد.

هدف ایجاد تعادل میان هزینه امروز و رشد آینده است.

۱۰ اشتباه رایج در طراحی زیرساخت

چند اشتباه بارها در شرکت‌ها تکرار می‌شوند.

اول، خرید بر اساس قیمت و بدون سناریو.

دوم، انتخاب فایروال فقط بر اساس تعداد کاربر.

سوم، خرید NAS فقط بر اساس ظرفیت فعلی.

چهارم، یکی دانستن RAID و Backup.

پنجم، نبود نسخه Offsite.

ششم، استفاده از شبکه Flat بدون Segment بندی.

هفتم، نادیده گرفتن ظرفیت شبکه داخلی.

هشتم، استفاده از حساب‌های مدیریتی مشترک.

نهم، طراحی فقط برای امروز.

دهم، تست نکردن Restore.

هرکدام از این اشتباهات ممکن است تا روز بحران پنهان بمانند.

قبل از خرید تجهیزات چه اطلاعاتی آماده کنیم؟

برای اینکه طراحی دقیق‌تر انجام شود، سازمان بهتر است اطلاعات اولیه را آماده کند.

تعداد کاربران،

تعداد سایت‌ها و شعب،

پهنای باند،

نوع سرویس‌ها،

تعداد ماشین‌های مجازی،

حجم داده،

نرخ رشد سالانه،

تعداد دوربین‌ها،

VPN،

تجهیزات فعلی،

محدودیت بودجه،

و زمان قابل‌تحمل قطعی.

این اطلاعات باعث می‌شود پیشنهاد فنی از حالت کلی خارج شود.

طراحی خوب الزاماً گران‌ترین طراحی نیست

یکی از سوءبرداشت‌ها این است که طراحی حرفه‌ای یعنی خرید گران‌ترین تجهیزات.

این تصور اشتباه است.

طراحی حرفه‌ای یعنی تناسب.

ممکن است یک شرکت کوچک با یک سرور، NAS مناسب، فایروال متناسب و بکاپ Offsite ساده نیاز خود را پوشش دهد.

در مقابل، سازمان بزرگ ممکن است نیاز به Cluster، چند مسیر ارتباطی، Replication و DR Site داشته باشد.

هزینه باید بر اساس ریسک واقعی تعیین شود.

جمع‌بندی

زیرساخت IT یک شرکت باید به‌صورت یک سیستم واحد دیده شود.

سرور بدون Storage مناسب ممکن است گلوگاه داشته باشد.

NAS بدون Backup Policy امن نیست.

فایروال بدون طراحی دسترسی و Segment بندی کافی نیست.

بکاپ بدون تست Restore قابل اعتماد نیست.

شبکه داخلی ضعیف می‌تواند عملکرد بهترین سرور و Storage را محدود کند.

به همین دلیل، طراحی باید قبل از خرید انجام شود.

اول سناریو مشخص شود.

سپس ظرفیت مورد نیاز تعیین گردد.

بعد امنیت، ذخیره‌سازی، شبکه و بازیابی کنار یکدیگر طراحی شوند.

در نهایت، محصول مناسب انتخاب شود.

یک زیرساخت موفق الزاماً گران‌ترین تجهیزات را ندارد.

اما اجزای آن با یکدیگر هماهنگ هستند.

کاربر، سرور، شبکه، فایروال، ذخیره‌ساز و بکاپ همگی در یک معماری مشخص قرار دارند.

این هماهنگی است که زیرساخت را پایدار، قابل توسعه و قابل بازیابی می‌کند.

سؤال نهایی برای هر شرکت باید این باشد:

اگر تعداد کاربران دو برابر شود، داده‌ها رشد کنند، یک شعبه اضافه شود یا یک سرویس حیاتی از دسترس خارج شود، آیا معماری فعلی هنوز پاسخگو خواهد بود؟

اگر پاسخ این سؤال مشخص نیست، زمان بازنگری در طراحی زیرساخت رسیده است.