پایداری سرویس‌ها در پیک‌ترافیک با لود بالانسینگ نوبر

📈 در بازه‌های پرترافیک مثل بلک‌فرایدی، فشار ناگهانی درخواست‌ها می‌تواند باعث کندی یا از دسترس خارج شدن سرویس‌ها شود؛ مشکلی که بسیاری از پلتفرم‌ها در این زمان تجربه می‌کنند.

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

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

⚙️ در روزهایی که ترافیک چند برابر می‌شود، لود بالانسینگ همان عاملی است که کمک می‌کند سرویس پایدار بماند و دچار اختلال نشود.

🔗 برای مطالعه نسخه کامل این مطلب، به لینک زیر مراجعه کنید:

Link

☁️@NobarCloud

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

مدل «Pay as you go» این مشکل رو حل می‌کنه! شما فقط برای منابعی که واقعاً استفاده می‌کنید هزینه می‌دید و می‌تونید منابع رو طبق نیاز خودتون تنظیم کنید.

این مدل پرداخت برای هر کسب و کاری بهینه و منطقی تر هستش!

جزئیات بیشتر در لینکدین

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

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

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


جزئیات بیشتر در لینکدین

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

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

جزئیات بیشتر در لینکدین

تو IaaS، زیرساخت فقط یه سرور روشن نیست؛ سیستم طوری طراحی می‌شه که با رفتار ترافیک تطبیق پیدا کنه. وقتی تعداد درخواست‌ها ناگهان ۳ برابر می‌شه، نودهای جدید بالا میان، CPU و RAM بیشتری تخصیص داده می‌شه و سرویس بدون افت کیفیت ادامه می‌ده. وقتی پیک تموم شد، منابع آزاد می‌شن و فقط هزینه مصرف واقعی پرداخت می‌شه.
همین منطق تو اجرای AI هم مهمه. پروژه yzma کمک می‌کنه مدل‌های هوش مصنوعی طوری اجرا شن که شبیه یه سرویس ابری واقعی رفتار کنن، نه یه اسکریپت سنگین روی یه ماشین تنها.
مثلاً مدل روی ۳ نود اجرا شده. اگر یکی به هر دلیلی down بشه، لودبالنسر سریع اون نود رو از چرخه خارج می‌کنه و ترافیک می‌ره سمت نودهای سالم؛ کاربر نه ارور می‌بینه، نه کندی حس می‌کنه.

با yzma:
۱. وابستگی مستقیم به SaaS خارجی نداری
۲. می‌تونی روی VM، Bare Metal یا کلاستر ابری خودت deploy کنی
۳. رفتار سیستم قابل پیش‌بینی و مقیاس‌پذیر می‌شه.
اگه تا دیروز IaaS رو برای وب‌سرورها و دیتابیس‌ها می‌شناختیم، امروز با ابزارهایی مثل yzma همون الگو برای مدل‌های هوش مصنوعی تکرار می‌شه: مقیاس‌پذیر، resilient و تحت کنترل خودمون.




@NobarCloud ☁️

جریان حمله دستکاری توکن GitHub (PAT)
امروز حمله‌ها فقط از «کلاد» شروع نمی‌شن، خیلی وقت‌ها از گیت‌هاب شروع می‌شن و آروم‌آروم می‌رسن به کنترل‌پلین فضای ابری.
سناریو چی بوده؟
اول مهاجم به یه Personal Access Token (PAT) دست پیدا می‌کنه؛ مثلاً از طریق فیشینگ، ریپازیتوری‌های عمومی یا توکن‌هایی که بد اسکوپ شدن می‌تونه ریپازیتوری‌ها رو بگرده، اسم secretها رو پیدا کنه، بفهمه CI/CD چطوری کار می‌کنه
حالا اگه دسترسی نوشتن هم داشته باشه، قضیه جدی‌تر می‌شه.
مهاجم می‌تونه Github Action رو تغییر بده یا workflow جدید بسازه و کد دلخواه رو اجرا کنه.
اینجاست که خیلی از تیم‌ها، کلیدهای AWS / Azure / GCP رو داخل GitHub Secrets نگه می‌دارن. گیتهاب اکشن اجرا می‌شه، secretها داخل محیط runtime در دسترسن و مهاجم می‌تونه اون‌ها رو از طریق لاگ یا خروجی‌ها استخراج کنه.
مهاجم با همون کلیدها وارد Cloud Control Plane می‌شه:
۱. کاربر جدید می‌سازه
۲. دسترسی‌ها رو بالا می‌بره
۳. منابع ابری رو کنترل می‌کنه
نکته اینه که خیلی از این کارها لاگ واضح ندارن یا بین تیم Dev و Cloud گم می‌شه و دیر متوجه بشی که حمله از کجا شروع شده.
منبع

@NobarCloud ☁️

وقتی Docker و SSL دست‌به‌گریبان می‌شن
توی دنیای واقعیِ سرورها و میکروسرویس‌ها، ارتباط امن با HTTPS و TLS حرف اول رو می‌زنه. تو یکی از پروژه‌ها، تیم Luca Baggi با یه خطای عجیب توی محیط Production روبه‌رو شد:
برنامه نمی‌تونست با یه سرویس خارجی از طریق HTTPS و mTLS ارتباط برقرار کنه و خطای TLS Handshake Failure می‌داد. یعنی ارتباط امن از همون اول شکست میخورد.
مشکل چی بود؟
وقتی تیم فنی توی محیط لوکال تست گرفت، با دستور openssl خیلی راحت تونست به سرور وصل بشه.
این یعنی:
کلاینت سالم بود و گواهی‌ها درست بودن اما به محض اینکه برنامه داخل Docker اجرا می‌شد اون هم با Distroless ایمیج، اتصال امن کلاً fail می‌شد.
راه‌حل؟
در عین سادگی، خیلی مهم بود:
۱. اضافه کردن Root CA موردنیاز به لیست ca-certificates
۲. ساختن یه Docker ایمیج جدید تا گواهی به‌عنوان گواهی قابل اعتماد شناخته بشه

به‌طور کلی:
گواهی‌ها از ایمیج Distroless اصلی برداشته شدن
داخل یه Debian Slim ایمیج قرار گرفتن
و اونجا با openssl تست گرفتن تا مطمئن بشن همه‌چیز درسته

گاهی مشکل TLS اصلاً از خود TLS نیست، از یه Root CA جاافتاده توی ایمیجه.

منبع

@NobarCloud ☁️

وقتی لینوکس رکورد IPO رو شکست:

توی اوج حباب دات‌کام، شرکتی به اسم VA Linux که سرور و سیستم‌های آماده با لینوکس می‌فروخت، در ۹ دسامبر ۱۹۹۹ وارد بورس شد و تاریخ ساخت.

قیمت هر سهم در IPO حدود ۳۰ دلار بود، اما همون روز اول تا حدود ۲۳۹ دلار بالا رفت؛
یعنی نزدیک به ۷۰۰٪ رشد در یک روز؛ رکوردی که سال‌ها دست‌نخورده موند.
شرکت تونست حدود ۱۳۲ میلیون دلار سرمایه جذب کنه؛ حتی بیشتر از مایکروسافت در زمان IPO خودش.
اما این موفقیت، بیشتر حاصل هیجان بازار بود تا قدرت واقعی کسب‌وکار.
با ترکیدن حباب دات‌کام، قیمت سهم سقوط کرد و در مدت کوتاهی به چند دلار رسید.
مدل کاری شرکت هم به مشکل خورد:
فروش سخت‌افزار لینوکسی، با ورود بازیگرهای بزرگی مثل Dell و عمومی‌شدن پشتیبانی Linux، دیگه مزیت رقابتی نبود.

بعدش چی شد؟
فروش سخت‌افزار کنار گذاشته شد
اسم شرکت به VA Software و بعد Geeknet تغییر کرد
و در نهایت VA Software سال ۲۰۱۵ توسط GameStop خریداری شد

منبع

@NobarCloud ☁️

وقتی GPUهای فوق‌سنگین هم مجازی می‌شن
در این مقاله، تیم UbiCloud توضیح می‌ده چطور تونستن ماشین‌های NVIDIA HGX B200 رو با روش‌های متن‌باز برای اجرای ماشین مجازی‌های GPU‌دار آماده کنن؛ کاری که به‌خاطر معماری خاص B200 حتی از H100 هم پیچیده‌تره.

دلیل پیچیدگی اینجاست که B200ها به‌صورت داخلی از NVLink و NVSwitch استفاده می‌کنن تا چند GPU با پهنای باند بسیار بالا به هم وصل باشن، اما همین ساختار، مجازی‌سازی رو سخت‌تر از GPUهای معمولی PCIe می‌کنه.

سه روش اصلی برای مجازی‌سازی روی این سخت‌افزار وجود داره: ۱. در حالت Passthrough کامل، یک یا چند GPU مستقیماً به یک VM داده می‌شن؛ یا هر هشت GPU با هم، یا به‌صورت جدا بدون NVLink.
۲. در حالت اشتراک‌گذاری با NVSwitch، GPUها گروه‌بندی می‌شن و هر گروه (۱، ۲، ۴ یا ۸ GPU) همچنان پهنای باند NVLink کامل رو حفظ می‌کنه.
۳. در روش vGPU slicing، منابع یک GPU بین چند VM تقسیم می‌شن و بیشتر برای بارهای سبک‌تر مناسبه.
به‌دلیل نیاز به تعادل بین کارایی و انعطاف‌پذیری، تیم UbiCloud در نهایت از مدل Shared NVSwitch استفاده کرده؛ مدلی که امکان ساخت VMهای ۱ تا ۸ GPU رو فراهم می‌کنه بدون اینکه پهنای باند داخلی از بین بره.
در مسیر پیاده‌سازی، چند چالش مهم وجود داشت:
لازم بود GPUها برای passthrough از درایور معمولی جدا و به کرنل مناسب bind بشن
نسخه درایور NVIDIA روی Host و داخل VM باید دقیقاً یکی باشه تا CUDA درست کار کنه
برای شبیه‌سازی توپولوژی واقعی PCIe، استفاده از QEMU ضروری بود
حجم بالای PCI BAR در B200 باعث کندی شدید بوت می‌شد که با تنظیمات خاص و نسخه‌های جدید QEMU برطرف شد
در نهایت، وقتی همه این لایه‌ها درست کنار هم قرار بگیرن، می‌شه روی HGX B200 با ابزارهای متن‌باز، ماشین‌های مجازی با دسترسی کامل به GPUهای بسیار قدرتمند ساخت.

منبع:
UbiCloud Blog
@NobarCloud ☁️

اختلال برق در NIST Boulder باعث از دست رفتن زمان دقیق NTP شد

توی این ایمیل که در لیست NANOG منتشر شده، گزارش شده که سرویس زمان اینترنت (NTP) در مرکز NIST Boulder به‌خاطر قطع طولانی برق شهری با مشکل جدی روبه‌رو شده.

طبق گزارش:
تأمین برق در ۱۷ دسامبر ۲۰۲۵ قطع شده و باعث از دست رفتن منبع زمانی دقیق بوردل شده.
سرورهای زمان هنوز با ژنراتور پشتیبان روشن هستن، اما احتمال قطع شدن اونا وجود داره چون یکی از ژنراتورها دچار خرابه.
چندین سرور NTP مثل time-a-b.nist.gov تا time-e-b.nist.gov و ntp-b-nist.gov (که سرویس NTP تاییدشده ارائه می‌دن) تحت تأثیر هستن.
تیم NIST هنوز زمان دقیق برطرف شدن مشکل رو نمی‌دونه و تمرکز فعلی‌شون بر آوردن منبع برق جایگزینه تا کل سیستم پایش و زمان سالم بمونه.
ایمیل رو Anne Johnson با استناد به پیام اصلی از طرف تیم سرویس زمان اینترنت NIST منتشر کرده.
منبع:
Nanog.or
@NobarCloud ☁️

وقتی پای Self-Host کردن PostgreSQL به میان میاد

خیلی‌ها فکر می‌کنن Self-Host کردن دیتابیس مثل PostgreSQL ترسناک و غیرقابل مدیریته مخصوصاً در مقایسه با سرویس‌های managed مثل RDS که همه‌چیز رو برایت می‌گیرن.
اما تجربه واقعی چیز دیگریه:
وقتی خودت دیتابیس رو روی سرور خودت می‌ذاری، به‌مراتب ارزان‌تر و قابلیت تنظیم بهتر می‌گیری، با همان قابلیت اعتماد که managed‌ ها ادعا می‌کنن.

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

چرا Self-Host؟
چون دیتابیس داخل خودت کنترل کامل داره و می‌تونی تنظیماتش رو طبق نیازت بهینه کنی.
وقتی دیتابیست down می‌شه، چه managed باشه چه خودت میزبانی کنی، در هر صورت آخرش خودت باید واکنش نشون بدی.

چه زمانی Self-Host منطقی نیست؟
۱. وقتی تازه شروع کردی و فقط می‌خوای سریع راه بندازی، managed راحت‌تره.
۲. وقتی شرکت خیلی بزرگه و استخدام مهندس DB به‌صرفه‌تره.
۳. وقتی محدودیت‌های قانونی یا compliance سخت‌تری داری.
چیزی که باید جدی بگیری:
وقتی خودت Postgres رو میزبانی می‌کنی، باید تنظیمات حافظه، connection، و بکاپ‌ها رو خودت انجام بدی تا از performance و reliability خوب بهره‌مند بشی.

مدیریت دیتابیس نیازی به ترس نداره. اگر هزینه‌ت برای managed بیش از حد باشه، یک سرور تست راه بنداز و Postgres رو امتحان کن، شاید برات ساده‌تر و به‌صرفه‌تر از چیزی باشه که فکر می‌کردی.

منبع:
pierce.de

@NobarCloud ☁️

وقتی آینده‌ی رایانش کوانتومی جدی‌تر از همیشه می‌شه

در آخرین پست بلاگ Scott Aaronson، بحث درباره اینه که چقدر احتمال داره تا چند سال آینده رایانش کوانتومی مفید و fault-tolerant واقعاً محقق بشه، یعنی ماشینی که بتونه الگوریتم‌هایی مثل Shor رو با خطاهای مدیریت‌شده اجرا کنه. بعد از شرکت در کنفرانس Q2B و دیدن پیشرفت‌های واقعی در سخت‌افزار (مثل سیستم‌های Ion-trap، QuEra، Quantinuum و چیپ‌های Google/IBM)، دیدگاهش نسبت به «آینده‌ی نزدیک» کوانتوم بیشتر مثبت شده، هرچند هنوز نمی‌دونه دقیقاً کی این اتفاق می‌افته. از نظرش در ۲۰۲۵، برخی پلتفرم‌ها به فیدلیتی بالای 99.9٪ رسیده‌ان، سطحی که آستانه‌ی fault-tolerance رو امکان‌پذیر می‌کنه.
در یک مصاحبه‌ی مرتبط با موضوع نیز به این نکته اشاره شد که اگر قبل از انتخابات ریاست‌جمهوری ۲۰۲۸، یک کامپیوتر کوانتومی fault-tolerant بتونه حتی کاری ساده مثل فاکتور کردن عدد ۱۵ با الگوریتم Shor انجام بده، اون رو «احتمال زنده» می‌دونه نه قطعیت، بلکه چیزی مثل “نه مطمئنم نمی‌شه”.
نویسنده همچنین بین دو نوع شرکت‌ها تفکیک قائل شده:
۱. گروهی که واقعاً روی مشکلات علمی واقعی کار می‌کنن
۲. گروهی که فقط روایت‌های جذاب برای سرمایه‌گذاران و دولت‌ها می‌سازن بدون اینکه لزوماً پیشرفت فنی پشتش باشه.

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

منبع:

scottaaronson.blog

@NobarCloud ☁️

وقتی دیتابیس‌ها باید برای SSD آپدیت بشن

توی این پست، Marc Brooker بررسی می‌کنه که دیتابیس‌های کلاسیک مثل PostgreSQL و MySQL که در دهه‌های ۹۰ و ۲۰۰۰ طراحی شدن، برای دیسک‌های چرخان قدیمی بهینه‌سازی شده بودن، جایی که I/O بسیار کند بود و کارایی با خواندن ترتیبی داده‌ها تعیین می‌شد. اما امروزه SSDها، هزار برابر سریع‌تر هستن و این یعنی معماری سنتی دیتابیس‌ها دیگه همیشه بهترین انتخاب نیست.

وقتی SSD رو در نظر می‌گیریم، دو بحث مهم پیش میاد:
۱. کش مناسب: SSDها سریعن، اما هنوز RAM ازشون خیلی سریع‌تره. به همین دلیل، دیتابیس باید کش رو جوری تنظیم کنه که بخش مهم داده‌ها (که احتمال دسترسی دوباره دارن) توی حافظه بمونه نه روی SSD
۲. سازماندهی I/O: درواقع SSDها نسبت به read/write حساسیت متفاوت دارن و بهترین کارایی وقتی به‌دست میاد که اندازه‌ی تراکنش‌ها و الگوهای دسترسی با سرعت و IOPS SSD هماهنگ باشن.

نقش سرورهای ابری چیه؟
۱. وقتی دیتابیس‌ها روی سرور ابری اجرا می‌شن، علاوه بر سرعت SSD، شبکه‌های دیتاسنتر هم وارد جریان می‌شن
۲. پهنای باند بین AZها در سرور ابری خیلی بالاست و latency بسیار پایینه
۳. نوشتن داده‌ها در چند دیتاسنتر مختلف (Replication) اهمیت بالایی پیدا میکنه و این یعنی دیتابیس‌های مدرن باید Design‌شون طوری باشه که Durability و Availability واقعی رو بدون وابستگی به SSD یه سرور تنها تضمین کنن.

در عمل به این معنیه که:
هارد SSD برای throughput و IOPS عالیه، ولی برای durability و failover، باید دیتابیس Replicate بشه (مثلاً توی مناطق مختلف ابر)، latency کم شبکه‌ی ابری به دیتابیس کمک می‌کنه تا commitها سریع‌تر از SSD محلی هم بشه.

نتیجه Brooker اینه که اگر بخوایم یه دیتابیس تازه از صفر برای محیط‌های SSD و ابری ۲۰۲۵ طراحی کنیم، باید:
۱. کش هوشمند داشته باشه تا hot set داده‌ها همیشه توی RAM بمونه
۲. طراحی I/O pattern رو حول سرعت SSD تنظیم کنه
۳. موارد replication و durability رو جدی بگیره چون دیگه نمی‌تونی به SSD یه سرور تنها اعتماد کنی و از latency و throughput شبکه‌ی دیتاسنتر ابری بهره ببری تا هر چیزی از local storage فراتر بره.
۴. دیتابیس‌های سنتی برای SSD خوب کار می‌کنن، اما بهترین نتیجه وقتی به دست میاد که طراحی از اول با توانایی SSD و امکانات ابری تطبیق داده بشه.

منبع:
brooker.co.za

What Does a Database for SSDs Look Like?

@NobarCloud ☁️