وضعیت هارددیسک‌ها در سرورها

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

  • ۷۲۰۰ RPM LFF
    • Today’s capacity point is 2 TB.  This is available in both SATA and SAS versions on the AMS2000 family, and in a SATA version on the USP V and VSP.
    • This platform is actively under development: ۳ TB SATA models are already available in retail stores from multiple vendors, and SAS 3 TB models are expected soon.
  • ۷۲۰۰ RPM SFF
    • Both the VSP and AMS2000 product lines support 7200 LFF drives which have twice the capacity, so for now we are offering only the LFF 7200 RPM models.
  • ۱۰K LFF
    • Long dead.
  • ۱۰K SFF SAS
    • Today’s capacity points are 300 GB and 600 GB.
    • This form factor is currently the mainstream platform in enterprise HDDs, so we expect higher capacity 10K SFF models over time.
  • ۱۵K LFF
    • The ۱۵K 600 LFF drive was the end of the line, and no higher capacity 15K LFF drives are expected.
  • ۱۵K SFF SAS
    • Today’s capacity point is 146 GB
    • Seagate has a 300 GB drive but we are not carrying this product because it is twice as expensive as a 10K RPM 300 GB SFF drive, but has much less than twice the performance.
    • Hitachi GST says they plan no further 15K SFF drives at this time.

شاید در مورد هارد‌هایی که از تکنولوژی SSD استفاده می‌کنند، اطلاعات کمی در اختیار شما بگذارد، اما مطالبی که در مورد نحوه محاسبه IOPS بیان کرده‌است، خواندنی و کاربردی است. این نوشته را در Putting HDD Product Trends Into Perspective: A Subsystem View بخوانید.

بازیابی اطلاعات در لینوکس

اگر به صورت اشتباهی (و یا حتی عمدی) فایل هایی را از روی فایل سیستم لینوکس خود پاک کردید ۲ روش کمی قابل اطمینان برای بازگرداندن فایل های پاک شده وجود دارد. روش اول در صورتی است که به احتمال بسیار کمی از فایل سیستم ext2 استفاده می کنید. در این حالت مجموعه ابزار debugfs می تواند به شما کمک کند. برای این مورد می توانید این راهنما را بخوانید: Undeleting files on the Linux ext2 filesysten with debugfs and e2undel

debugfs برای ext3 و ext4 به شما کمکی نخواهد کرد. برای بازیابی اطلاعات فایل های خود در لینوکس با فایل سیستم ext3 و ext4 یکی از بهترین ابزارها extundelete می باشد. این ابزار فعلا در مخازن استاندارد وجود ندارد ولی به راحتی در خانواده دبیان می توانید آن را نصب و راه اندازی کنید. بعد از اینکه سورس برنامه را دانلود کردید نیاز دارید آن را کامپایل و سپس با کمی حوصله و مطالعه از آن استفاده کنید. برای کامپایل به هدرهای e2fsprogs و e2fslibs نیاز دارید. همچنین اگر پیش از این برنامه ای را از سورس کامپایل نکردید می بایست پیشنیازهای gcc را هم نصب کنید. به ترتیب این مراحل را نیاز خواهید داشت:

$ su –
# apt-get install build-essential
# apt-get install checkinstall
# apt-get install fsprogs
# apt-get install fslibs e2fslibs-dev

root@mira:/opt# cd extundelete-0.1.8/
root@mira:/opt/extundelete-0.1.8# cd src/
root@mira:/opt/extundelete-0.1.8/src# make

بعد از اینکه extundelete نصب شد می توانید با استفاده از راهنمای Recognized options of extundelete 0.1.8 به عملیات پر خیر و برکت بازیابی بپردازید. در حالت پیش فرض فایل هایی را که بازیابی کرده است در پوشه ای به اسم RECOVERED_FILES بازیابی می کند. اگر فایل را قدیم تر پاک کرده باشید و نتواند نام اصلی را بازیابی کند از inodeکد استفاده می کند. سعی کنید اگر فایل مهمی را پاک کرده اید و می خواهید بازیابی انجام دهید در کمترین زمان ممکن و بدون فعالیت اضافه ای این کار را انجام دهید. بدیهی است این روش ها هیچ ضمانت اجرایی ندارد و هرآنچه انجام می دهید به مسولیت خود شماست.

روز قدردانی از SysAdminها مبارک!


Tunneling with Free BSD



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.

تبریک به
بابک خان برای کتابشون

Network Administration with FreeBSD 7

OpenSparc و نوآوری های سان میکروسیستمز

شرکت سان میکروسیستمز با اعلام توسعه OpenSparc امکان فعالیت بیشتری برای علاقه مندان به معماری CPUها و به خصوص آشنایی بیشتری با ساختار خانواده SPARC را فراهم کرده است. با پیشرفت خوب این پروژه و اعلام آماده شدن Niagara II، اهداف این پروژه به واقعی تر شدن نزدیک می شود. برای یک مرور کلی مراجعه کنید به مطلب زیر:


Technical look at Niagara II

The gross overview is eight in-order cores on a die, each capable of running multiple threads, same as Niagara (N1).
Niagara 2 (N2) does quite a lot more, it executes two groups of four threads per core instead of four, and pulls large chunks of the north bridge on board.

In terms of raw die size, it hasn’t changed all that much, Niagara was 378 mm^2 and Niagara 2 is 342 mm^2. Once you factor in that Niagara the elder was on a 90nm process and Niagara 2 is 65, you can see that the new chip would be about twice as big on a similar process. It also runs at a similar speed, 1.2 and 1.4GHz are the launch fequencies.

چند مقایسه هم بین محصولات Sun، IBM،  Dell و HP را در اینجا بخوانید. بر طبق پیشبینی  ها محصولات خانواده Niagara II با ۸هسته و مجموع ۲۰۴۸ thread قابل اجرا به زودی در دسترس خواهند بود: Sun preps 2048-thread monster

۱۰ مورد قابل توجه در سیستم مانیتورینگ مراکز داده

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

میزان دسترسی

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

میزان دسترسی % Downtime در سال Downtime در ماه Downtime  در هفته
۹۰% ۳۶٫۵ days ۷۳ hours ۱۶٫۸۴ hours
۹۵% ۱۸٫۲۵ days ۳۶٫۵ hours ۸٫۴۲ hours
۹۸% ۷٫۳۰ days ۱۴٫۴ hours ۳٫۳۶ hours
۹۹% ۳٫۶۵ days ۷٫۲۰ hours ۱٫۶۸ hours
۹۹٫۵% ۱٫۸۳ days ۳٫۶۰ hours ۵۰٫۴ min
۹۹٫۹% ۸٫۷۶ hours ۴۳٫۲ min ۱۰٫۱ min
۹۹٫۹۹% ۵۲٫۶ min ۴٫۳۲ min ۱٫۰۱ min
۹۹٫۹۹۹% ۵٫۲۶ min ۲۵٫۹ s ۶٫۰۵ s
۹۹٫۹۹۹۹% ۳۱٫۵ s ۲٫۵۹ s ۰٫۶۰۵ s