هاست پرترافیک برای سایتی است که یک سرور یا هاست پربازدید دیگر جواب ترافیکش را نمیدهد. در این معماری چند سرور بار را بین خود تقسیم میکنند و اگر یکی از کار بیفتد، سایت روشن میماند. کانفیگ سرور این زیرساخت را با Load Balancing، تکثیر دیتابیس، کش Redis و CDN برای سایت یا اپلیکیشن شما طراحی و اجرا میکند و پیش از تحویل با تست خرابی آزمایش میکند.
این خطاها معمولاً یعنی منابع سرور یا ظرفیت پردازشهای PHP-FPM به سقف رسیده و درخواستها در صف ماندهاند. ارتقای پشتسرهم پلن هاست سقف را فقط کمی جابهجا میکند و در اوج بعدی همان مشکل برمیگردد.
وقتی وبسرور، دیتابیس و فایلها روی یک سرورند، همان سرور نقطه شکست واحد (Single Point of Failure) است. در معماری High Availability میتوان سرورها را یکییکی از مدار خارج کرد و بدون قطعی سایت نگهداری کرد.
کوئریهای کند، قفل جدولها و نبود کش شیء معمولاً زودتر از کمبود CPU خود را نشان میدهند. گاهی بهینهسازی دیتابیس کافی است و گاهی تفکیک و تکثیر دیتابیس لازم میشود.
ترافیک را بین چند وبسرور تقسیم میکنیم، دیتابیس و فایلها را بین سرورها هماهنگ نگه میداریم و پاسخهای تکراری را کش میکنیم. برای هر جزء هم مسیر جایگزینی میسازیم که هنگام خرابی وارد مدار شود.
لود بالانسر ورودی سایت است و درخواستها را بین سرورها پخش میکند.
اگر فقط یک لود بالانسر وجود داشته باشد، خرابی همان یکی کل سایت را از دسترس خارج میکند.
همان داده روی بیش از یک سرور نگهداری میشود تا با خرابی یک سرور از دست نرود.
کش، کارهای تکراری PHP و دیتابیس را کم میکند.
فایلهای ایستا از نقطهای نزدیک به کاربر تحویل میشوند و فایلهای آپلودی روی همه سرورها یکسان میمانند.
تعداد و اندازه سرورها با اندازهگیری تعیین میشود.
هاست پرترافیک دو مشکل متفاوت را حل میکند: کم آمدن ظرفیت در ساعت اوج و قطع شدن سایت وقتی یک سرور از کار میافتد. مشکل اول گاهی با بهینهسازی یا سرور بزرگتر برطرف میشود. برای مشکل دوم به چند سرور و مسیر جایگزین نیاز دارید. فروشگاه یا اپلیکیشنی که هر دقیقه قطعیاش فروش یا کاربر از دست میدهد، معمولاً با هر دو روبهروست. نکتههای زیر به مدیر فنی یا صاحب کسبوکار کمک میکند پیش از صرف هزینه بداند در کدام مرحله است و از پیمانکار چه بخواهد.
اضافه کردن سرور به سایتی که کوئریهای کند دارد، همان کندی را روی چند سرور تکرار میکند. پس کار با اندازهگیری شروع میشود. لاگهای وبسرور نشان میدهند اوج درخواستهای همزمان کی و چقدر است، slow query log کوئریهای سنگین را پیدا میکند و پایش منابع معلوم میکند CPU، رم یا دیسک زودتر پر میشود. گاهی تنظیم PHP-FPM، کش صفحه یا اصلاح چند ایندکس کافی است و این کار در بهینهسازی سرور انجام میشود.
قدم بعدی معمولاً جدا کردن دیتابیس از وبسرور است، چون این دو الگوی مصرف متفاوتی دارند و بعد از جدا شدن میتوان هر کدام را جداگانه بزرگ کرد. Object Cache با Redis و کش صفحه در Nginx یا LiteSpeed هم بار PHP را کم میکنند. اگر بعد از این مراحل گلوگاه باقی بود، یا قطعی هنگام نگهداری دیگر قابل قبول نبود، نوبت چند وبسرور پشت لود بالانسر است. تست بار با k6 یا JMeter پیش و پس از هر مرحله نشان میدهد ظرفیت واقعاً بالا رفته است یا نه.
اپلیکیشنی که برای یک سرور نوشته شده، معمولاً فرض میکند فایلها، Session و کارهای زمانبندیشده روی همان ماشین هستند. پشت لود بالانسر این فرضها خطا میسازند. کاربر روی یک سرور وارد میشود و درخواست بعدیاش به سروری میرسد که Session او را ندارد، یا تصویری که روی یک نود آپلود شده روی نود دیگر پیدا نمیشود. پیش از انتقال، این موارد باید حل شوند:
بخشی از این تغییرات به کد اپلیکیشن برمیگردد. بازنویسی کد خارج از این خدمت است، اما نیازها را فهرست میکنیم و به تیم توسعه میدهیم. وردپرس و ووکامرس با پوشه uploads مشترک، Object Cache در Redis و یک cron سیستمی روی یک نود بهجای WP-Cron، روی چند سرور کار میکنند و Session ووکامرس هم در دیتابیس ذخیره میشود.
لود بالانسر تکی رایجترین اشتباه است. دو وبسرور پشت یک HAProxy با خاموش شدن همان HAProxy از دسترس خارج میشوند. برای همین لود بالانسر دوم با Keepalived و IP شناور راهاندازی میشود، اگر دیتاسنتر IP شناور را پشتیبانی کند. Failoverی هم که هیچوقت آزمایش نشده قابل اعتماد نیست. تا وقتی یک نود را عمداً خاموش نکردهاید، نمیدانید Health Check درست تنظیم شده، Replica بهروز است یا اپلیکیشن بعد از جابهجایی دوباره به دیتابیس وصل میشود.
کلاستری که نود کافی ندارد هم مشکلساز است. MariaDB Galera و Redis Sentinel برای جلوگیری از split-brain دستکم سه عضو رأیدهنده میخواهند و با دو عضو، قطع ارتباط بین آنها معمولاً نوشتن یا Failover را متوقف میکند. اشتباه دیگر این است که High Availability را جایگزین بکاپ بدانید. حذف اشتباه یا داده آلوده فوراً روی همه نودها تکثیر میشود، پس بکاپ مستقل و برنامه بازیابی همچنان لازم است و در بکاپ و بازیابی بحران طراحی میشود.
محل کاربران تعیین میکند CDN و سرورها کجا باشند. برای کاربران داخل ایران CDN و سرور داخلی مناسبترند و برای مخاطب خارج از ایران CDN خارجی. اگر سایت هر دو گروه را دارد، این انتخاب را پیش از طراحی مشخص کنید. امکاناتی مثل IP شناور و شبکه خصوصی بین سرورها در همه دیتاسنترها یکسان نیست، پس پیش از طراحی Failover آنها را از ارائهدهنده سرور بپرسید.
تعداد و اندازه نودها پایه برآورد است و روش تکثیر دیتابیس عامل مهم بعدی. Replication ساده با یک Replica زودتر از Galera Cluster سهنودی راه میافتد و نگهداری سادهتری دارد. نیاز به CDN، همگامسازی فایلها و حجم دادهای که باید منتقل شود هم زمان کار را تغییر میدهد. آماده بودن اپلیکیشن هم اثر زیادی دارد، چون اگر تیم توسعه باید Session یا مسیر آپلود را تغییر دهد، اجرا به برنامه زمانی آنها وابسته میشود.
لازم نیست همه اجزا یکجا ساخته شوند. مسیر مرحلهای، از جدا کردن دیتابیس تا لود بالانسر دوتایی، هزینه را با رشد ترافیک هماهنگ میکند. برای بررسی اولیه، آدرس سایت، پلتفرم، حدود ترافیک در اوج و مشکل فعلی را بفرستید. نگهداری زیرساخت بعد از تحویل را هم میتوانید در قالب پشتیبانی و مدیریت سرور ادامه دهید.
پیش از طراحی Failover لود بالانسر، از ارائهدهنده سرور بپرسید IP شناور پشتیبانی میشود یا نه. بدون آن، جابهجایی خودکار به روش دیگری نیاز دارد.
همه سایتهای پربازدید به کلاستر نیاز ندارند. این جدول کمک میکند پیش از صرف هزینه، مرحله فعلی خود را تشخیص دهید.
| گزینه | چه زمانی کافی است | محدودیت |
|---|---|---|
| هاست پربازدید اشتراکی | سایت محتوایی با ترافیک رو به رشد و بدون جهش ناگهانی | منابع مشترک با سایتهای دیگر و کنترل محدود روی تنظیمات سرور |
| سرور مجازی یا اختصاصی قویتر (مقیاس عمودی) | وقتی گلوگاه فقط CPU یا RAM است و قطعی کوتاه هنگام نگهداری قابل تحمل است | سقف سختافزاری و همچنان یک نقطه شکست |
| چند سرور با Load Balancing و HA (مقیاس افقی) | فروشگاه یا اپلیکیشنی که قطعی آن مستقیماً درآمد را کم میکند یا ترافیک جهشی دارد | پیچیدگی و هزینه بیشتر؛ اپلیکیشن باید برای اجرای چندسروره آماده شود |
اگر در یکی از دو مرحله اول هستید، هاست لینوکس، هاست فروشگاهی یا سرور مجازی ایران معمولاً انتخاب اقتصادیتری است.
لاگهای وبسرور، مصرف منابع، کوئریهای کند و الگوی اوج ترافیک را بررسی میکنیم. گاهی مشکل با بهینهسازی سرور حل میشود و به چند سرور نیازی نیست.
تعداد نودها، نقش هر سرور، روش تکثیر دیتابیس، محل نگهداری Session و فایلها و مسیر Failover را مستند میکنیم و پیش از اجرا با شما نهایی میکنیم.
زیرساخت را روی سرورهای جدید آماده میکنیم و داده را منتقل میکنیم. بعد با تست بار و خاموشکردن عمدی اجزا، رفتار سیستم در خرابی را پیش از تغییر DNS بررسی میکنیم.
مستندات معماری، داشبورد پایش و روال Failover را تحویل میدهیم. نگهداری ماهانه این زیرساخت را میتوانید در قالب پشتیبانی و مدیریت سرور ادامه دهید.
این خدمت بخشی از مجموعه زیرساخت سرور و وب کانفیگ سرور است و با همان ابزارهایی اجرا میشود که در مدیریت روزمره سرورهای لینوکسی به کار میبریم.
لازم نیست از روز اول کلاستر کامل بسازید. مسیر مرحلهای، از جداکردن دیتابیس تا لود بالانسر دوتایی، متناسب با رشد ترافیک پیشنهاد میشود.
HAProxy، Nginx، Keepalived، MariaDB و Redis روی سرور مجازی، اختصاصی یا ابر خصوصی شما اجرا میشوند و قابل انتقالاند.
پیش از تحویل، هر لایه را یک بار عمداً از مدار خارج میکنیم و رفتار سایت، Replica و Health Checkها را بررسی میکنیم.
راهنمای HAProxy در لینوکس روی همین سایت منتشر شده و همان اصول در این خدمت به کار میرود.
هاست پرترافیک زیرساختی است که برای تحمل تعداد زیادی درخواست همزمان و ادامه کار هنگام خرابی طراحی شده است. نسخه اشتراکی آن که «هاست پربازدید» هم نامیده میشود فقط منابع بیشتری دارد. نسخه کامل، چند سرور پشت یک لود بالانسر است که هیچکدام نقطه شکست واحد نیستند.
لود بالانسینگ یعنی توزیع درخواستهای کاربران بین چند سرور. لود بالانسری مثل HAProxy یا Nginx جلوی سرورها قرار میگیرد، سلامت هر سرور را با Health Check میسنجد و هر درخواست را طبق الگوریتم تعیینشده به یکی از سرورهای سالم میفرستد.
High Availability یعنی سرویس با خرابی یک جزء قطع نشود و جایگزین بکاپ نیست. بکاپ برای برگرداندن داده پس از حذف یا خرابی است، در حالی که حذف اشتباه یا داده آلوده در HA فوراً روی همه نودها تکثیر میشود. هر دو، همراه با یک برنامه Disaster Recovery، لازماند.
به لایه بستگی دارد. برای وب، دو سرور پشت دو لود بالانسر حداقل منطقی است. MariaDB Galera و Redis Sentinel برای جلوگیری از split-brain به حداقل سه نود یا سه عضو رأیدهنده نیاز دارند و در Galera میتوان نود سوم را یک arbitrator سبک گذاشت.
بله، به شرط آنکه پوشه uploads بین سرورها مشترک باشد، Object Cache در Redis نگهداری شود و WP-Cron با یک cron سیستمی روی یک نود جایگزین شود. Session ووکامرس در دیتابیس ذخیره میشود و با دیتابیس مشترک مشکلی ایجاد نمیکند.
نه. CDN برای فایلهای ایستا و صفحههای قابل کش بخش بزرگی از بار را برمیدارد، اما درخواستهای پویا مثل سبد خرید، پرداخت، جستوجو و پنل کاربری همچنان به سرور مبدأ میرسند و ظرفیت آن باید جداگانه تأمین شود.
هزینه به تعداد و اندازه نودها، روش تکثیر دیتابیس، نیاز به CDN و پیچیدگی انتقال بستگی دارد. پس از بررسی اولیه رایگان، معماری پیشنهادی و برآورد هزینه را اعلام میکنیم. برای استعلام قیمت در تلگرام پیام دهید.
آدرس سایت، پلتفرم (مثلاً وردپرس، لاراول یا Node.js)، حدود ترافیک در اوج و مشکل فعلی را در تلگرام بفرستید. بعد از بررسی اولیه رایگان، معماری پیشنهادی هاست پرترافیک را دریافت میکنید.
