جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
به اشتراک بگذارید
جدید!
سرور ابری ساعتی فعال شد. ۱۰۰ هزار تومان اعتبار هدیه بگیرید
قطعی برق سرور در دفتر تقریباً همیشه به یک عدد خلاصه می‌شود: دقیقه‌هایی که باتری UPS دوام می‌آورد. برای بار رک حدود ۴۰۰ وات، یک UPS کوچک در عمل چیزی در حد ده دقیقه می‌دهد و عدد دقیقش از نمودار runtime همان مدل درمی‌آید. بعد از آن سرور بدون خروج منظم خاموش می‌شود و خطر از برق به فایل‌سیستم و دیتابیس می‌رسد.
| موضوع | اتاق سرور دفتر | دیتاسنتر |
|---|---|---|
| برق | یک فید شهری و باتری محدود | چند فید، UPS با بای‌پس و ژنراتور |
| سرمایش | کولر معمولی، بدون افزونگی | سرمایش طراحی‌شده با افزونگی |
| دسترسی فیزیکی | فوری؛ کلید دست خودتان | کنترل‌شده و زمان‌بر |
| تأخیر شبکه | کمترین؛ همان LAN | وابسته به خط اینترنت دفتر |
| هزینه | خرید دارایی و نگهداری | اجاره ماهانه و هزینه مهاجرت |
💡 خلاصه در چهار خط
خاموشی بدون خروج منظم یعنی برق رفته و سرور فرصت بستن فایل‌ها و تراکنش‌ها را نداشته است.
✅ اول عدد بسازید: حاشیه سود از دست رفته در هر ساعت توقف، توان واقعی رک، و زمان تخمینی باتری.
✅ بعد هر دو مسیر را قیمت بگذارید: تقویت برق دفتر، یا انتقال به دیتاسنتر.
ترتیب کار در این مقاله از عدد شروع می‌شود، نه از توصیه. ابتدا زیان هر ساعت توقف را روی کاغذ می‌آورید، بعد توان رک را به ظرفیت UPS و دقیقه ترجمه می‌کنید. سپس می‌بینید خاموشی ناگهانی در فایل‌سیستم و دیتابیس چه خرابی‌ای می‌سازد، و آخر نقشه انتقال و سوال‌هایی که باید از میزبان بپرسید.
📌 آنچه در این مقاله می‌خوانید
◀️ هزینه واقعی خاموشی را با عددهای خودتان بسنجید
◀️ محاسبه ظرفیت UPS و ژنراتور برای اتاق سرور
◀️ خاموشی ناگهانی با فایل‌سیستم و دیتابیس چه می‌کند
◀️ نقشه انتقال سرویس‌ها و مهاجرت سرور فیزیکی به مجازی
هزینه واقعی قطعی برق سرور را با عددهای خودتان بسنجید
زیان یک ساعت توقف، حاشیه سودی است که از دست می‌رود، به‌علاوه کاری که باید دوباره انجام شود و جریمه‌ای که واقعاً بدهکار می‌شوید. درآمد ناخالص زیان نیست، و دستمزد هم پیشاپیش داخل همان درآمد است.
فرمول هزینه هر ساعت توقف
دو خطا این حساب را خراب می‌کند: گذاشتن فروش ناخالص به‌جای حاشیه سود، و افزودن دستمزد روی درآمد که دوبار شمردن است. دستمزد فقط جایی شمرده می‌شود که کارمند حقوق می‌گیرد و کاری ندارد.
# برگه محاسبه؛ همه مقادیر جای‌نگهدار است و با عدد خودتان پر می‌شود
# A = فروش معدوم در هر ساعت توقف (نه فروش معوق)
# m = حاشیه سود ناخالص، مثلا 0.30
# lost_margin = A * m
# rework = هزینه دوباره‌کاری و اضافه‌کار هر ساعت
# penalty = جریمه قراردادی هر ساعت، اگر واقعا بدهکار می‌شوید
# idle_pay = دستمزد ساعتی نفراتی که حقوق می‌گیرند و بی‌کار می‌مانند
# hourly_loss = lost_margin + rework + penalty + idle_payساعت خاموشی ماهانه را حدس نزنید؛ از لاگ خودِ UPS یا دفتر ثبت قطعی‌ها بردارید. حاصل‌ضرب این دو عدد، سقف بودجه‌ای است که منطقی است صرف حل مسئله کنید. بعد هر دو مسیر را با همان واحد قیمت بزنید. یک طرف تقویت برق دفتر است: UPS بزرگ‌تر، باتری، ATS و بردن کولر روی برق اضطراری. طرف دیگر اجاره ماهانه یک سرور مجازی ایرانی به‌علاوه هزینه یک‌باره مهاجرت.
هزینه‌های پنهان اتاق سرور که در بودجه دیده نمی‌شوند
تقریباً تمام توان برقی سرور به گرما تبدیل می‌شود و همان گرما باید از اتاق بیرون برود. با فرض ضریب عملکرد حدود ۳ برای کولر گازی، هر ۳ وات گرما نزدیک به ۱ وات برق اضافه می‌خواهد؛ پس رک ۴۰۰ واتی حدود ۵۳۰ وات بار برقی می‌سازد. این ضریب تخمینی است و در تابستان پایین‌تر می‌رود.
- برق سرور و برق سرمایش، دو قلم جدا در صورت‌حساب
- تعویض دوره‌ای باتری UPS، که با دمای بالای اتاق جلو می‌افتد
- سرویس کولر، برقکاری رک و اجاره فضای اتاق
- وقت تیم فنی برای پاسخگویی شب و تعطیلات
🔸 بار حرارتی را از روی پلاک تغذیه حساب نکنید
پلاک پاور حداکثر توان را نشان می‌دهد، نه مصرف واقعی. مصرف را با کلمپ‌متر روی کابل رک بخوانید و میانگین ساعت شلوغی را بردارید؛ اختلاف این دو روی سرورهای کم‌بار چشمگیر است.
محاسبه ظرفیت UPS و ژنراتور برای اتاق سرور؛ از وات تا دقیقه
ظرفیت UPS با VA نوشته می‌شود و بار شما با وات؛ پس اول واحدها را یکی کنید، بعد سربار اطمینان را اضافه کنید و در آخر از ظرفیت باتری به دقیقه برسید.
تبدیل وات به VA و انتخاب ظرفیت
طبق مستندات Eaton رابطه این دو ساده است: «Watts = VA * Power Factor». همان مرجع می‌گوید ضریب توان سرورهای جدید معمولاً ۰.۹ یا بیشتر است. برای ظرفیت هم یک قاعده می‌دهد: «a VA rating that is 1.2x the total load». تقسیم بر ۰.۷۵ که در همان صفحه دیده می‌شود قاعده دوم نیست؛ فقط داخل مثال خودِ Eaton با بار و ضریب توان دیگری آمده است.
# برگه محاسبه؛ هر سطر یک گام است، نه کد اجراشدنی
# بار واقعی رک: 400 W
# ضریب توان سرورهای جدید، طبق Eaton: 0.9
# بار ظاهری: 400 / 0.9 = 445 VA
# سربار پیشنهادی Eaton: 445 * 1.2 = 534 VA
# انتخاب: نزدیک‌ترین مدل بالاتر از 534 VAرسیدن از ظرفیت باتری به دقیقه
دقیقه‌های پشتیبان را انرژی ذخیره‌شده در باتری و بار لحظه‌ای تعیین می‌کند، نه برچسب VA روی UPS.
# برگه محاسبه سقف نظری زمان پشتیبان
# minutes = (Ah * V_string * DoD * eff * 60) / load_W
# Ah: ظرفیت اسمی باتری
# V_string: ولتاژ رشته؛ دو باتری 12V سری = 24V
# DoD = 0.8 و eff = 0.9 : فرض تقریبی ما، نه عدد منبع‌دار
# نمونه: 9Ah , 24V , 400W -> 23 minاین ۲۳ دقیقه سقف نظری است. ظرفیت مؤثر باتری سربی با نرخ تخلیه کم می‌شود، پس هرچه بار نسبت به ظرفیت باتری سنگین‌تر باشد فاصله از این سقف بیشتر است. ستون آخر جدول زیر تخمین ما است؛ عدد قابل اتکا فقط نمودار runtime سازنده برای همان مدل و همان بار است.
| بار رک و رشته باتری | نرخ تخلیه | سقف نظری | بازه تخمینی ما |
|---|---|---|---|
| ۴۰۰ وات، ۲۴ ولت ۹ آمپرساعت | حدود ۱.۸۵C | ۲۳ دقیقه | ۸ تا ۱۲ دقیقه |
| ۷۰۰ وات، ۲۴ ولت ۱۸ آمپرساعت | حدود ۱.۶۲C | ۲۷ دقیقه | ۱۰ تا ۱۴ دقیقه |
| ۱۲۰۰ وات، ۴۸ ولت ۱۰۰ آمپرساعت | حدود ۰.۲۵C | ۱۷۳ دقیقه | ۱۴۰ تا ۱۶۵ دقیقه |
ستون آخر سیاست خاموشی شما را می‌سازد. اگر ده دقیقه وقت دارید، UPS فقط یک کار می‌تواند بکند: خاموش‌کردن منظم سرور. پس NUT یا نرم‌افزار سازنده باید نصب و تست شده باشد تا در آستانه شارژ مشخص، سرویس‌ها و بعد سیستم‌عامل را مرتب ببندد. قطعی برق سرور وقتی خطرناک است که این زنجیره تست نشده باشد.
# تست زنجیره خاموشی خودکار با NUT، روی سرور و با دسترسی root
# خواندن وضعیت و درصد شارژ باتری
upsc upsname
# تست درایور، بدون اجرای واقعی
upsdrvctl -t start
# شبیه‌سازی خاموشی اجباری؛ سرور واقعا خاموش می‌شود، پس فقط در پنجره سرویس
upsmon -c fsdعمر باتری با گرم‌شدن اتاق سرور کوتاه می‌شود
عمر باتری‌های VRLA که در بیشتر UPSها هستند را دما تعیین می‌کند. سازنده Riello UPS می‌نویسد «High ambient temperature is the most important factor that influences UPS battery ageing». عمر طراحی این باتری‌ها بر پایه دمای بهینه ۲۰ تا ۲۵ درجه سلسیوس تعیین شده و به گفته همان مرجع عموماً پذیرفته شده است که برای هر ۱۰ درجه افزایش پایدار بالاتر از آن نصف می‌شود. عمر طراحی را از برگه مشخصات باتری خودتان بردارید.
ژنراتور چه الزاماتی اضافه می‌کند
ژنراتور جای UPS را نمی‌گیرد؛ مکمل آن است. طبق سند پرسش‌های متداول Cummins درباره NFPA 110 (۲۰۱۹)، تنها الزام قطعی این استاندارد زمان استارت است: ژنراتور باید در ۱۰ ثانیه برق را به بار برساند. همان ۱۰ ثانیه را UPS پر می‌کند.
ژنراتور هم جایی جواب درست است: وقتی سرویس باید در خودِ ساختمان بماند، مثل کنترلر دامین یا داده‌ای که قرارداد اجازه خروجش را نمی‌دهد.
- کلید انتقال خودکار (ATS) که بار را به ژنراتور می‌دهد و برگشت را هم مدیریت می‌کند
- خودگردانی سوخت: مخزن ۲۰۰ لیتری با مصرف ۱۰ لیتر در ساعت یعنی حدود ۲۰ ساعت
- تهویه هوای ورودی و خروج دود، فونداسیون و کنترل صدا
- تست دوره‌ای با بار واقعی؛ استارت بی‌بار چیزی را ثابت نمی‌کند
⚠️ همزمانی خرابی را دست‌کم نگیرید
در اتاق سرور دفتر، کولر معمولاً به برق اضطراری وصل نیست. نتیجه این است که UPS برق سرور را نگه می‌دارد، اما دما بالا می‌رود و سرور با هشدار حرارتی خاموش می‌شود. کولر را یک بار در ساعت خلوت خاموش کنید و ببینید اتاق در پانزده دقیقه چند درجه بالا می‌رود.
خاموشی ناگهانی با فایل‌سیستم و دیتابیس چه می‌کند
خاموشی ناگهانی معمولاً دیسک را خراب نمی‌کند، اما داده‌های لحظه‌های آخر و محتوای فایل‌های تازه‌نوشته‌شده را از بین می‌برد. مستندات ext4 و PostgreSQL این را با جزئیات می‌گویند و جدی‌بودن قطعی برق سرور را روشن می‌کنند.
لایه فایل‌سیستم: ژورنال چه چیزی را نجات می‌دهد و چه چیزی را نه
در مستندات ext4 در کرنل لینوکس (نسخه ۷.۳.۰ سند) حالت پیش‌فرض data=ordered است؛ یعنی داده پیش از ثبت متادیتای آن در ژورنال نوشته می‌شود. همان سند درباره بازه commit می‌گوید بعد از قطع برق «you will lose as much as the latest 5 seconds of metadata changes»، اما فایل‌سیستم به‌لطف ژورنال آسیب نمی‌بیند. هشدار مهم‌تر این است: «due to delayed allocation even older data can be lost on power failure»، چون نوشتن این داده‌ها تا پایان بازه dirty_expire_centisecs شروع نمی‌شود.
در عمل یعنی ژورنال ساختار فایل‌سیستم را سالم نگه می‌دارد، نه محتوای فایل‌هایی که همان لحظه نوشته می‌شدند.
لایه دیتابیس: کش نوشتن، خطر واقعی است
مستندات PostgreSQL (نسخه جاری سند، ۱۸) شرط دوام تراکنش را این‌طور می‌نویسد: داده هر تراکنش تأییدشده باید در جایی ذخیره شود که «safe from power loss, operating system failure, and hardware failure» باشد. بعد سراغ سخت‌افزار می‌رود: کش کنترلر دیسک «can be a reliability hazard because the memory in the disk controller cache is volatile». درباره دیسک‌ها هم می‌گوید «Consumer-grade IDE and SATA drives are particularly likely to have write-back caches that will not survive a power failure».
همان سند مسئولیت را روی دوش مدیر سیستم می‌گذارد: «it is the administrator’s responsibility to make certain that all storage components ensure integrity […]». توصیه‌اش روشن است: کنترلر با کش نوشتن بدون باتری را کنار بگذارید، و اگر دیسک تضمینی ندارد کش write-back را خاموش کنید. برای MySQL و SQL Server همین بحث زیر نام innodb_flush_log_at_trx_commit و sync_binlog دنبال می‌شود.
# دیدن و خاموش‌کردن کش نوشتن دیسک، با دسترسی root
# وضعیت فعلی کش نوشتن
hdparm -W /dev/sda
# خاموش‌کردن کش نوشتن
hdparm -W 0 /dev/sda
# همان پرسش روی دیسک SAS
sdparm --get=WCE /dev/sda
# سنجش دوام fsync
pg_test_fsync
# هشدار: کارایی نوشتن محسوس پایین می‌آید
# هشدار: تنظیم hdparm پس از ریبوت پاک می‌شود؛ در udev یا یک یونیت systemd ثابتش کنید| لایه | در خاموشی ناگهانی چه از دست می‌رود | کاری که باید بکنید |
|---|---|---|
| فایل‌سیستم | متادیتای چند ثانیه آخر و فایل تازه | ماندن روی data=ordered |
| کش کنترلر و دیسک | هرچه در کش فرار بود | کنترلر با باتری یا خاموشی کش |
| دیتابیس | تراکنش تأییدنشده و صفحه نیم‌نوشته | فعال‌ماندن fsync و full_page_writes |
| اپلیکیشن | فایل موقت و صف کار | صف پایدار روی دیسک |
⚠️ fsync را برای سرعت خاموش نکنید
خاموش‌کردن fsync یا گذاشتن کش write-back بدون باتری، سرعت را بالا می‌برد و دوام را از بین می‌برد. PostgreSQL درباره حافظه هم فرض می‌کند «you will operate using RAM that uses industry standard Error Correcting Codes (ECC) or better protection».
بکاپی که بازگردانی‌اش تست نشده، بکاپ نیست.
نقشه انتقال سرویس‌ها به دیتاسنتر و مهاجرت سرور فیزیکی به مجازی
انتقال یک‌شبه همه‌چیز بدترین روش است. ترتیب درست این است که سرویس‌های کم‌وابستگی و پرریسک را اول ببرید، و در هر مرحله راه برگشت داشته باشید.
اولویت‌بندی سرویس‌ها؛ کدام اول برود
| سرویس | حساسیت به خاموشی | اولویت انتقال |
|---|---|---|
| سایت و فروشگاه | بالا | اول |
| ایمیل و DNS | بالا؛ وابستگی بیرونی | اول |
| حسابداری و ERP | متوسط؛ وابسته به ساعت کاری | دوم |
| کنترلر دامین و فایل سرور | وابسته به شبکه محلی | در دفتر می‌ماند |
مهاجرت سرور فیزیکی به مجازی (P2V) قدم‌به‌قدم
مهاجرت P2V یعنی ساختن تصویری از سرور فیزیکی و بالاآوردن همان سیستم روی ماشین مجازی. ریسک اصلی، درایور و شناسه سخت‌افزار است.
- فهرست‌برداری سرویس‌ها، پورت‌ها، یونیت‌های systemd و لایسنس‌های گره‌خورده به سخت‌افزار
- آماده‌سازی درایور virtio روی سیستم مبدأ، پیش از گرفتن تصویر
- گرفتن تصویر در حالت سرد با ابزاری مثل virt-v2v یا Clonezilla
- بالاآوردن تصویر روی مقصد و اصلاح شبکه، نام میزبان و مسیر دیسک
- فعال‌سازی دوباره لایسنس ویندوز یا ERP گره‌خورده به سخت‌افزار
- کم‌کردن TTL رکوردهای DNS چند روز قبل
- پنجره انتقال نهایی با سینک تفاضلی و تغییر DNS؛ سرور قدیمی سالم بماند
دسترسی کارمندان بعد از انتقال
بعد از انتقال، سرویس‌ها از IP عمومی در دسترس‌اند و لایه دسترسی باید بسته شود. برای SSH از کلید استفاده کنید و ورود با رمز را ببندید. پورت RDP را روی اینترنت باز نگذارید و به IP مجاز دفتر محدود کنید. سرویس‌های وب با HTTPS و احراز هویت دومرحله‌ای منتشر شوند.
سوال‌هایی که باید از میزبان بپرسید
ادعای «دیتاسنتر استاندارد» به‌تنهایی چیزی ثابت نمی‌کند؛ مدرک ثابت می‌کند. محدوده دمای سالن یکی از همین مدارک است. جدول راهنمای ASHRAE ویرایش ۲۰۱۵ با اصلاحیه ۲۵ جولای ۲۰۱۶، که آزمایشگاه ملی لارنس برکلی در وبینار ۱ نوامبر ۲۰۱۷ منتشر کرده، برای کلاس‌های A1 تا A4 دمای خشک ۱۸ تا ۲۷ درجه سلسیوس را توصیه می‌کند. نقطه شبنم هم از منفی ۹ درجه تا سقف همزمان ۱۵ درجه و ۶۰ درصد رطوبت نسبی است. حد پایین را جا نیندازید؛ هوای خیلی خشک خطر تخلیه الکترواستاتیک دارد. ASHRAE بعدتر ویرایش ۲۰۲۱ را منتشر کرده است.
- برق: چند مسیر ورودی، نوع UPS، و گزارش آخرین تست ژنراتور با بار
- سرمایش: افزونگی واحدها و نمودار دما و رطوبت یک ماه گذشته
- شبکه: تعداد مسیرهای بالادست و رفتار سرویس در قطع یکی از آن‌ها
- عملیات: کنترل تردد، فرایند تیکت و شرط‌های جبران قرارداد
نوشته انتخاب دیتاسنتر مناسب برای سرور مجازی همین پرسش‌ها را از زاویه معماری باز می‌کند.
🔶 چه چیزی مهاجرت را کم‌دردتر می‌کند
سرور مجازی ایران وب‌داده در دیتاسنتر تهران و روی شبکه رسپینا میزبانی می‌شود و هر سرور IP مستقیم دارد که از اینترنت بین‌الملل هم در دسترس است. برای کار مهاجرت، پنل اختصاصی با اسنپ‌شات، حالت Rescue، کنسول VNC و نصب ISO دلخواه کار می‌کند.
یک تذکر برای تصمیم‌گیری: مهاجرت، مسئله قطعی برق سرور را حل می‌کند نه مسئله بکاپ را. حتی روی زیرساخت دیتاسنتر، سیاست بکاپ و تست بازگردانی باید مال خودتان باشد.
سوال‌های پرتکرار درباره خاموشی، برق اضطراری و انتقال سرور
چند دقیقه برق اضطراری برای سرور کافی است؟
به اندازه زمان بستن سرویس‌ها و سیستم‌عامل، به‌علاوه حاشیه اطمینان؛ این زمان را یک بار با کرنومتر اندازه بگیرید. اگر برنامه‌تان ادامه کار است، UPS کافی نیست.
آیا UPS خانگی برای سرور مناسب است؟
برای سرور تولیدی معمولاً نه، اما دلیلش «نداشتن خروجی داده» نیست: بسیاری از مدل‌های خانگی مثل خانواده APC Back-UPS پورت USB دارند و NUT از آن‌ها پشتیبانی می‌کند. تفاوت واقعی، ظرفیت کم باتری و شکل موج شبه‌سینوسی در مدل‌های ارزان است.
پیام «اتصال به سرور برقرار نشد» بعد از خاموشی چه معنایی دارد؟
یعنی سرویس شبکه مقصد پاسخ نمی‌دهد. دلیل رایج این است که سرویس در بوت بالا نیامده یا به دیسکی وابسته است که دیرتر mount شده؛ اول لاگ بوت را ببینید، بعد شبکه را.
تفاوت اختلال مقطعی با خاموشی کامل چیست؟
اختلال مقطعی یعنی افت یا قطع کوتاه که تجهیز ممکن است تحملش کند؛ خاموشی کامل یعنی قطع ادامه‌دار. برای اولی حفاظت ولتاژ مهم است، برای دومی ظرفیت انرژی.
خاموشی ناگهانی چه آسیبی به RAID می‌زند؟
ریسک اصلی، کش کنترلر بدون باتری است؛ همان چیزی که مستندات PostgreSQL آن را reliability hazard می‌نامد. وضعیت باتری کنترلر را با ابزار مدیریت خودش بررسی کنید.
مهاجرت سرور فیزیکی به مجازی چقدر طول می‌کشد؟
زمان واقعی را حجم داده و پهنای باند تعیین می‌کند. بخش فنی چند ساعت است، اما کپی اولیه داده چند روز طول می‌کشد؛ پنجره قطع نهایی فقط برای سینک آخر است.
اگر اینترنت دفتر قطع شود، چه اتفاقی می‌افتد؟
سرویس برای کاربران بیرونی سر جایش است، چون به خط دفتر وابسته نیست؛ اما کارمندان تا برگشت اینترنت دسترسی ندارند.
آیا ژنراتور جای یوپی‌اس را می‌گیرد؟
نه. ژنراتور برای استارت و پذیرش بار زمان می‌خواهد و در همان فاصله سرور خاموش می‌شود. UPS آن شکاف را پر می‌کند.
جمع‌بندی؛ تصمیم را با عدد بگیرید
قطعی برق سرور یک مسئله مهندسی است و با سه عدد حل می‌شود: زیان واقعی هر ساعت توقف، توان واقعی رک، و زمان تخمینی باتری. عدد اول حاشیه سود از دست رفته است، نه فروش ناخالص؛ دستمزد را فقط آنجا اضافه کنید که کارمند حقوق می‌گیرد و بی‌کار مانده است. عدد دوم را با کلمپ‌متر می‌خوانید، نه از پلاک پاور. عدد سوم از فرمول انرژی باتری می‌آید، اما با نرخ تخلیه بار شما تغییر می‌کند و مرجع نهایی‌اش نمودار runtime سازنده است. وقتی این سه عدد روی کاغذ باشند، هر دو مسیر را با همان واحد قیمت بزنید: تقویت برق و سرمایش دفتر، یا انتقال سرویس‌ها به دیتاسنتر با هزینه یک‌باره مهاجرت. گاهی جواب درست ماندن است، مثل سرویسی که باید روی شبکه محلی بماند. و یک کار را عقب نیندازید: بازگردانی بکاپ را تست کنید.
🚀 قدم بعدی
اگر بعد از حساب‌کردن اعداد به انتقال رسیدید، گزینه‌های سرور مجازی ایران را ببینید.
اگر سوالی داشتید، در بخش نظرات با ما در ارتباط باشید.
منابع
