Tunneling with Free BSD

When talking about tunneling, different definitions come to people’s minds. Basically, tunneling is transmitting data that is encapsulated into a pipe, over a public network (for example, the Internet). However, there are different methods to tunnel data over a public network for different approaches. For example, when security is a concern, tunnel protocols with cryptography are more favorable. But when performance has higher priority, protocols with lower packet overheads will be chosen. FreeBSD 7 has a built-in support for a number of important tunneling protocols, although there are also many third-party applications in FreeBSD packages that support more tunneling protocols.

پایداری بسیاری از کسب و کارها به سرویس دهی و امنیت مناسب مرکز داده مورد استفاده بستگی دارد. ساختار فیزیکی دیتا سنترها شامل تجهیزات حیاتی مختلف، از تولید کنندگان مختلفی است. تجهیزاتی مانند روترها، سوییچ ها، PDUها، UPSها، تابلوهای برق، رک ها، تجهیزات امنیت فیزیکی، واحدهای تهویه (CRAC)، ژنراتورها و دوربین های حفاظتی هر کدام از چندین تولید کننده و با استاندارد های مختلفی هستند، مدیریت این ساختار پیچیده، نیاز به سیستمی دارد که بتواند با تولید کننده های مختلف ارتباط برقرار کند و برعکس ساختار پیچیده، مدیریت و مانیتورینگ را آسان کند. ۱۰ مورد زیر برای انتخاب راه حل های مانیتورنیگ مراکز داده می تواند مورد استفاده قرار بگیرد:

۱- هزینه عدم استفاده از سیستم مانیتورینگ را محاسبه کنید.

سیستم های مانیتورینگ مراکز داده می توانند گران قیمت باشند، اما هزینه سربار وقفه در سرویس دهی (Downtime) ممکن است هزینه بیشتری برای کسب و کار شما ایجاد کند. با تهیه هزینه خسارت های احتمالی در حالت بروز مشکل (با در نظر گرفتن هزینه های پنهانی مانند سخت افزار و تغییر ساختار) و همینطور هزینه یک سیستم مانیتورینگ می توانید تصمیم گیری موفق تری داشته باشید. همچنین دقت کنید سیستم های مانیتورینگ و تاثیر آن در کاهش هزینه، از عوامل مهم محاسبه ROI شما خواهد بود.

۲- لیست تمامی تجهیزاتی که می بایست کنترل شوند، را تهیه کنید.

البته حتما چنین لیستی از قبل تهیه کرده اید! این لیست برای دسته بندی محصولات موجود و انتخاب سیستم موثر بسیار کاربردی خواهد بود. بخش های مختلف این لیست می تواند شامل نام، مدل، تولیدکننده، سال تولید، نسخه نرم افزار، پروتکل های مورد پشتیبانی، امکان استفاده از API، امکان به روز رسانی، … باشد.

۳- راه حلی را انتخاب کنید که، دارای رابط گزارش دهی/گیری گرافیکی باشد.

لیستی از اعلان های خطر، ممکن است به صورت موردی بتواند منجر به رفع ایراد شود، اما در صورتی که از ابزار های بصری استفاده نکنید، فهم وضعیت در یک نگاه کلی کمی مشکل به نظر می آید. در همین مورد، با توجه به امکان گسترش ساختار مورد استفاده (چه در بعد فیزیکی و چه در بعد ارتباطی) این رابط گرافیکی می بایست قابل توسعه و انعطاف پذیر باشد. توجه کنید، رابط گرافیکی تنها قسمتی از واحد های ارائه گزارش است و سایر واحدها (مثل Email و SMS) نیز در جای خود قابل توجه هستند.

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

گسترش ساختار مورد استفاده (چه در بعد فیزیکی و چه در بعد ارتباطی) نیاز رعایت توسعه پذیری در آینده سیستم را مورد توجه قرار می دهد. این معماری علاوه بر توسعه پذیری در ابعاد کمی، می بایست قابلیت توسعه برای تطبیق با نرم افزارهای موجود را داشته باشد. به عنوان مثال یکپارچه سازی با CRM و یا قابلیت اتصال اطلاعات برای Helpdesk.

5- راه حلی را انتخاب کنید که از تمامی تجهیزات شما، پشتیبانی کند.

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

۶- برای استفاده از راه حل نرم افزاری و یا سخت افزاری تصمیم گیری کنید.

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

۷- راه حل هوشمندی را انتخاب کنید که قابلیت پردازش اعلان خطر (Alarm Processing) را داشته باشد.

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

۸- به دنبال پشتیبانی از پروتکل های مختلف باشید.

به علت ساده بودن پیاده سازی سیستم های تک پروتکل، تعداد این سیستم ها تا حدودی زیاد است. بهتر است برای یکپارچگی سیستم، از چندین پروتکل پشتیبانی انجام شود. به عنوان مثال تجهیزات الکترونیکی شما احتمالا از SNMP استفاده می کنند و ژنراتورها از Modbus استفاده می کنند.

۹- سعی کنید تمامی نیازهای منحصربفرد خود را پوشش دهید.

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

۱۰- پیش از تصمیم گیری به صورت آزمایشی از سیستم انتخابی استفاده کنید.

سیستم شما، بدون آزمایش ریسک بالایی برای کسب و کار شما خواهد داشت. اگر سیستم انتخابی نسخه آزمایشی ندارد، کمی در تصمیم گیری خود بیشتر تامل کنید.

طراحی سیستم ها با مشخص کردن یک مقیاس به عنوان معیار قابل دسترس بودن (درصد میزان دسترسی)، به صورت واقعی تا حدودی مشکل (غیر ممکن) است. وجود پارامترهای مختلفی که در سرویس دهی سیستم ها (چه سیستم های شبکه ای، چه سیستم های نرم افزاری) وجود دارند و غیر قابل کنترل بودن بعضی از این پارامتر ها از جمله مواردی است که باعث مشکل بودن این کار می شود. از مجموع ۸۷۶۰ ساعتی که در سال وجود دارد، بسته به حساسیت، اهمیت و حیاتی بودن سیستم، محدوده Uptime مشخصی برای سرویس دهی می بایست مورد هدف قرار بگیرد. جدولی برای این محدوده را که در حالت معمول تعداد ۹ها (Nines) آن را مشخص می کند، می تواند مشاهده کنید. (برای تفریح > Uptime-Project)