امارات در سایه حملات ایران، دیتاسنترهای هوش مصنوعی را به زیر زمین و داخل کوه‌ها می‌برد

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

تنش‌های منطقه‌ای باعث شد تا پروژه‌ی ۵ گیگاواتی ابوظبی به جای یک مجتمع واحد، به شبکه‌ای از تاسیسات امن تبدیل شود. تجهیزات دفاع هوایی و جنگ الکترونیک نیز به این مراکز اضافه خواهند شد.

@abrplusdocs

⚠️💢مصاحبه CNN با مهندس هوش‌مصنوعی شرکت آنتروپیک که روز گذشته از سمت خود استعفا داده و هشدار داده است که هوش‌مصنوعی ممکن است در آینده‌ای نزدیک بشریت را نابود کند!

@abrplusdocs

جنگ؛ تهدید یا یک فرصت در دل بحران؟

درگیری ایران و آمریکا فقط معادلات نظامی و سیاسی منطقه را تغییر نداده بلکه زیرساخت فناوری منطقه هم تحت تأثیر قرار گرفته است.

آسیب به برخی مراکز داده و زیرساخت‌های مرتبط با شرکت‌هایی مانند AWS و Oracle و افزایش نگرانی‌های امنیتی، می‌تواند شرکت‌های فناوری را به سمت کاهش ریسک و بازنگری در استقرار زیرساخت‌های خود در خاورمیانه سوق دهد.

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

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

اما یک چالش جدی وجود دارد:

🚧 لجستیک و بسته‌شدن مسیرهای ورودی

محدودیت‌های ایجادشده در مسیرهای دریایی جنوب و احتمال گسترش محدودیت‌ها به مسیرهای هوایی، می‌تواند انتقال تجهیزات به داخل کشور را بسیار دشوارتر کند.

در نتیجه، فعلاً نمی‌توان با قطعیت گفت این فرصت واقعاً شکل خواهد گرفت یا نه.

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

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

@abrplusdocs

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

این سیستم از کانکتوم واقعی مغز مگس توی FlyWire استفاده می‌کنه که شامل 139,255 نورون و حدود 15 میلیون اتصال هستش. پیکسل‌های تصویر پرچم وارد این شبکه میشن و فعالیت نورون‌ها توسط یه مدل آموزش‌دیده تحلیل میشه.

برای تشخیص پرچم، مدل با مجموعه‌ای از 256 طرح مختلف پرچم و تغییرات تصویری آموزش داده شد و تونست هر 550 نمونه‌ی آزمایشی از 550 نمونه رو درست تشخیص بده.

برای بخش سرود، متن سوگند وفاداری به کد مورس تبدیل شد و یه مدل GRU آموزش دید تا ترتیب نمادها رو یاد بگیره. مدل در epoch شماره‌ی 120 تونست هر 492 توکن رو دقیقاً درست تولید کنه. این سیستم فقط همین دنباله‌ی مشخص رو یاد گرفته و به معنی یادگیری زبان نیست.


@abrplusdocs

یه نفر اومده ویروس استاکس‌نت (stuxnet) همون که باهاش به مجتمع غنی سازی نطنز نفوز کردن رو مهندسی معکوس کرده و سورسشو گذاشته گیتهاب
اگه تو حیطه امنیت کار میکنید واقعا میتونه کلی یادگیری داشته باشه


github.com/Sadpainy/Stuxnet
@abrplusdocs

این سایته بهتون قول میده هر چیزی بخواید رو توی چند دقیقه یاد بگیرید واقعا خوبه ولی دیگه خیلی کوتاه و کلی گویی کرده :

learnxinyminutes.com


@abrplusdocs

وقتی تازه دوره هک OSWE رو گذروندی و می‌ری که اولین سایت دولتی ایران رو هک کنی😁

@abrplusdocs

🔴 کمپین جهانی سوءاستفاده از CVE-2026-59310 در vCenter — بدتر از چیزی که فکرش رو می‌کردیم

◀️ یادتونه چند وقت پیش درباره این باگ Directory Traversal تو vCenter صحبت کردیم؟ خب حالا شرکت آلمانی QUIRSO یه گزارش داده که نشون می‌ده ماجرا خیلی فراتر از یه اکسپلویت محدود بوده.
◀️ تیم تحقیقاتی QUIRSO فعالیت این کمپین رو در ۴۷ کشور مختلف ردیابی کرده، با آمریکا، فرانسه، ایران و ترکیه به‌عنوان بیشترین کشورهای هدف. جمعاً ۳۶۱ آدرس IP یکتا درگیر این حمله بودن.
◀️ نکته جالب اینه که این‌بار آلمان با ۵۵ مورد، آمریکا با ۴۱ مورد، ترکیه با ۳۸ مورد، ایران با ۲۶ مورد و فرانسه با ۲۵ مورد بیشترین آلودگی رو داشتن — یعنی این دفعه اروپا هم بی‌نصیب نمونده.
◀️ طبق گفته‌ی خود محققا، این فقط اسکن و تست نبوده؛ شواهد فارنزیک به‌وضوح نشون می‌ده که نفوذ واقعی رخ داده، نه صرفاً تلاش برای اکسپلویت.


#VMware #vCenter #CVE #APT #CloudSecurity

📱 @abrplusdocs

🟢 حمله زنجیره تأمین NPM رو آمازون به کره شمالی نسبت داد

◀️ تیم اطلاعاتی آمازون بالاخره چهار تا حمله جدا از هم به پکیج‌های NPM رو به هم ربط داد و همه‌شون رو به گروه Sapphire Sleet وابسته به کره شمالی نسبت داد.
◀️ یکی از این حمله‌ها همون ماجرای معروف هک پکیج‌های debug و chalk بود که تو کمتر از دو ساعت حدود ده درصد از محیط‌های ابری دنیا رو درگیر کرد — رقم ترسناکیه اگه بهش فکر کنید.
◀️ روش کارشون هم جالبه: مهندسی اجتماعی روی نگهدارنده‌های معتبر پکیج‌ها، تقسیم پیلود بین چند پکیج مختلف تا شناسایی سخت‌تر بشه، و حتی تکنیک‌هایی برای دور زدن دستیارهای کدنویسی هوش مصنوعی.
◀️ سطح اطمینان آمازون از این انتساب فعلاً متوسط اعلام شده، ولی الگوی حمله دقیقاً همون چیزیه که قبلاً از این گروه دیدیم.

🔐 اگه پایپ‌لاین CI/CD شما به‌صورت خودکار پکیج‌های NPM رو پول می‌کنه، این خبر یه یادآوری خوبه که Pin کردن نسخه‌ها و بررسی Dependency دیگه یه گزینه نیست، یه ضرورته.

#امنیت_زنجیره_تأمین #NPM #CloudSecurity #تهدید_سایبری

📱 @Abrplusdocs
t.me/abrplusdocs

🔵 یه سیستم چندعامله هوش مصنوعی ۸۴ آسیب‌پذیری تازه تو شبکه‌های نسل ۴ و ۵ پیدا کرد

◀️ خبر جالبی که این هفته توجه خیلی‌ها رو جلب کرد اینه که یه سیستم چند-ایجنتی مبتنی بر مدل‌های زبانی، تونسته ۸۴ باگ جدید تو پروتکل‌های هسته شبکه ۴G و ۵G کشف کنه، از جمله یه باگ Session Hijacking که تأیید هم شده.
◀️ نکته مهم‌تر از خود باگ‌ها اینه که چرا این اتفاق افتاد: رابط‌های سیگنالینگ داخلی مثل N4/PFCP و S11-S5/GTP-C از اول با فرض جداسازی فیزیکی طراحی شده بودن، ولی حالا که هسته شبکه Cloud-Native و کانتینری شده، این فرض دیگه درست نیست.
◀️ یعنی همون مشکلی که تو دنیای Cloud و Container زیاد باهاش سروکار داریم (اعتماد بیش‌ازحد به مرزهای شبکه داخلی) الان داره تو زیرساخت مخابراتی هم خودشو نشون می‌ده.

⚙️ برای هرکسی که تو حوزه Cloud یا Telco کار می‌کنه، این یه مثال خوبه از اینکه چرا Zero Trust فقط یه شعار مارکتینگی نیست؛ وقتی زیرساخت‌های قدیمی رو روی معماری جدید پیاده می‌کنیم، فرض‌های امنیتی قدیمی دیگه جواب نمی‌دن.

#امنیت_ابری #هوش_مصنوعی #۵G #ZeroTrust #تحلیل

📱 @Abrplusdocs
t.me/abrplusdocs

💥بحران قیمت‌گذاری VMware داره نقشهٔ بازار مجازی‌سازی رو عوض می‌کنه

بعد از خرید VMware توسط Broadcom، مدل لایسنس به‌کلی تغییر کرد: لایسنس دائمی (perpetual) کاملاً حذف شد و همه باید مشترک سالانه یا چندساله بشن، با حداقل ۷۲ هسته اجباری برای هر سازمان. کاتالوگ محصولات هم از بیش از ۸۰۰۰ SKU به چند باندل محدود مثل VMware Cloud Foundation و vSphere Foundation جمع شد و دیگه مسیر برگشت به لایسنس دائمی وجود نداره.

💢نتیجه؟ افزایش قیمت‌های نجومی. AT&T در دعوایی حقوقی از افزایش ۱۰۵۰ درصدی قیمت خبر داد و برخی ارائه‌دهندگان ابری اروپایی افزایش تا ۱۵۰۰ درصد رو گزارش کردن. گارتنر هم پیش‌بینی کرده تا ۲۰۲۸ حدود ۷۰ درصد مشتریان سازمانی VMware حداقل نیمی از بار کاری مجازی‌شون رو مهاجرت می‌دن.


این وضعیت داره مستقیماً به نفع پلتفرم‌های متن‌باز مثل OpenStack تموم می‌شه. طبق نظرسنجی Open Infrastructure Foundation، هشتادو دو درصد اعضاش گزارش دادن سازمان‌هایی به دنبال جایگزین VMware سراغشون اومدن، و ۶۱٪ هم موفق شدن حداقل یک مشتری VMware رو به OpenStack منتقل کنن.

از لحاظ فنی هم این انتخاب توجیه اقتصادی داره: در معماری‌های HCI متن‌باز مبتنی بر OpenStack و KVM، کاهش TCO در بازهٔ پنج‌ساله معمولاً بین ۴۰ تا ۶۰ درصد نسبت به دیپلوی معادل VMware گزارش می‌شه، چون KVM و OpenStack هزینهٔ لایسنس به ازای هستهٔ CPU ندارن و سخت‌افزار هم دیگه محدود به لیست سرتیفای‌شدهٔ یک وندور خاص نیست.


🔺نکتهٔ مهم برای تیم‌های IT: این مهاجرت رایگان و بدون چالش نیست — از سازگاری اپلیکیشن‌ها گرفته تا آموزش تیم، باید با برنامهٔ مرحله‌ای پیش رفت، نه یک‌شبه.
اما مسیر روشنه: هر چه وابستگی به یک وندور بیشتر باشه، هر تمدید قرارداد یعنی مذاکره از موضع ضعف.

#OpenStack #VMware #Broadcom #CloudInfrastructure #Virtualization #KollaAnsible #DataCenter

@abrplusdocs

دنیای جذاب VMware
از 2001 تا 2026

@abrplusdocs

🔴 دور زدن کامل احراز هویت در vCenter بدون نیاز به هیچ رمز عبوری

◀️ کنار همون آسیب‌پذیری معروف CVE-2026-59310 که قبلاً درباره‌ش گفتیم، یه باگ دیگه هم تو همون Advisory برادکام بود که شاید کمتر بهش توجه شده، ولی از نظر شدت اصلاً کمتر نیست: CVE-2026-59309.
◀️ این یکی تو سرویس VMware Directory Service (همون vmdir) هست، جایی که هویت کاربرا و اجزای vCenter مدیریت می‌شه. امتیازش هم دقیقاً مثل قبلی، ۹.۸ از ده.
◀️ نکته نگران‌کننده اینه که این یه Auth Bypass واقعیه، یعنی مهاجم اصلاً نیازی به هیچ اطلاعات ورود نداره؛ فقط کافیه به vCenter دسترسی شبکه‌ای داشته باشه.
◀️ محققای امنیتی گزارش دادن که تو محیط‌های واقعی، افزایش قابل توجهی تو اسکن و شناسایی سرورهای آسیب‌پذیر نسبت به همین باگ دیده شده — از جمله تست‌های مسیرهای مربوط به SAML/SSO که نشون‌دهنده شناسایی دقیق نسخه‌هاست.

🔐 اگه vCenter شما هنوز پچ VMSA-2026-0006 رو نگرفته، این دو باگ (59309 و 59310) رو با هم در نظر بگیرید؛ ترکیب Auth Bypass و RCE تو یه محیط، دقیقاً همون سناریوییه که تیم‌های امنیتی ازش کابوس می‌بینن.



#VMware #vCenter #AuthBypass #CVE #CloudSecurity

📱 @Abrplusdocs
t.me/abrplusdocs

🔴 یه کاربر Read-Only می‌تونه کل کلاستر Ceph شما رو دستش بگیره

◀️ آسیب‌پذیری CVE-2026-50152 تو Ceph پیدا شده : یه کاربر با دسترسی فقط Read only می‌تونه به مخزن Config-Key دسترسی پیدا کنه.
◀️ مشکل اینجاست که همین مخزن Config-Key، اطلاعات خیلی حساسی نگه می‌داره؛ از جمله رمزهای رمزنگاری دیسک OSD (LUKS) و کلیدهای خصوصی SSH که Cephadm برای دسترسی به هاست‌های کلاستر استفاده می‌کنه.
◀️ یعنی یه حساب کم‌دسترسی که فقط قرار بوده وضعیت کلاستر رو ببینه، عملاً می‌تونه از همون مسیر به کل کلاستر و حتی هاست‌های زیرینش دسترسی پیدا کنه.
◀️ نسخه‌های قبل از ۱۹.۲.۶ و ۲۰.۲.۴ تحت تأثیر هستن.

🔐 اگه Ceph شما پشت Cinder یا Glance تو محیط OpenStack کار می‌کنه، این یکی رو نادیده نگیرید. تا وقتی آپدیت نکردید، حداقل دسترسی mon allow r رو از کاربرای CephX که نیازی بهش ندارن بگیرید.

#Ceph #OpenStack #CVE #CloudSecurity #Storage

📱 @Abrplusdocs
t.me/abrplusdocs

🕵️ مردی که موتورولا رو بدون نوشتن حتی یک خط کد هک کرد
◀️ سال ۱۹۹۲، کوین میتنیک (یکی از معروف‌ترین هکرهای تاریخ) در حالی که از دست FBI فراری بود، تصمیم گرفت سورس‌کد گوشی موتورولا MicroTAC Ultralite رو به دست بیاره — همون گوشی پرچمدار اون دوره.

◀️ هدفش این بود که با دستکاری شماره سریال گوشی (ESN)، جلوی ردیابی خودش توسط پلیس رو بگیره. ولی راهی که برای رسیدن به این سورس‌کد انتخاب کرد، هیچ ربطی به کدنویسی یا اکسپلویت نداشت.

◀️ او فقط یه تماس تلفنی با موتورولا گرفت، خودش رو به چند بخش مختلف وصل کرد تا بالاخره به تیمی رسید که روی همون سورس‌کد کار می‌کردن، و با اعتمادبه‌نفس و لحن یه کارمند داخلی، اونا رو متقاعد کرد که خودش هم عضو همون تیمه و فوری به این فایل‌ها نیاز داره.

◀️ نتیجه؟ کمتر از بیست دقیقه بعد، کارکنان موتورولا خودشون فایل سورس‌کد رو از طریق FTP براش فرستادن — بدون اینکه حتی یک بار هویتش رو درست‌وحسابی چک کنن.
✅ این داستان دقیقاً همون چیزیه که بعد از این همه سال هنوز درسش زنده‌ست: قوی‌ترین فایروال دنیا هم فایده‌ای نداره اگه یه کارمند بشه با یه تماس تلفنی و کمی اعتمادبه‌نفس متقاعدش کرد. مهندسی اجتماعی هنوز هم موثرترین روش نفوذه، چون هدفش تکنولوژی نیست، آدماست.
#تاریخچه_هک #مهندسی_اجتماعی #Motorola #امنیت_سایبری
📱 @Abrplusdocs

t.me/abrplusdocs

🔴 زنجیره‌ای از دو باگ که یه کاربر ساده رو Admin می‌کنه

◀️ تو Keystone نسخه‌های قبل از ۲۹.۰.۲ یه سناریوی جالب کشف شده که وقتی دو تا مشکل رو با هم ترکیب کنی، نتیجه‌ش خیلی بدتر از هر کدوم به‌تنهایی می‌شه.
◀️ یه کاربر که فقط نقش Member رو تو یه پروژه داره، می‌تونه با ترکیب یه باگ Application Credential Impersonation و مکانیزم Trust های Keystone، دسترسیش رو تا سطح Admin بالا ببره.
◀️ نکته فنی جالب اینجاست: وقتی توکن جعل‌شده هویت قربانی رو حمل می‌کنه، از چک اعتبارسنجی Trustor عبور می‌کنه، ولی Keystone نقش‌های Trust رو بر اساس دیتابیس نقش‌های واقعی قربانی چک می‌کنه، نه نقش‌های توکن درخواست‌دهنده. همین ناهماهنگی راه رو باز می‌کنه.
◀️ بدتر از همه اینکه Trust ساخته‌شده مستقل باقی می‌مونه، یعنی مهاجم می‌تونه بعداً هم Trust و Credential های بیشتری بسازه تا دسترسیش رو حفظ کنه — و تمام این کارها تو لاگ‌ها به‌نام قربانی ثبت می‌شه، نه به‌نام مهاجم.

🔐 اگه از Application Credentials تو محیط چند-کاربره یا چند-پروژه‌ای استفاده می‌کنید، آپدیت به ۲۹.۰.۲ رو در اولویت بذارید؛ این نوع باگ‌ها معمولاً تو ممیزی امنیتی معمولی دیده نمی‌شن چون لاگ‌ها گمراه‌کننده‌ست.

#OpenStack #Keystone #CVE #KollaAnsible #CloudSecurity

📱 @Abrplusdocs
t.me/abrplusdocs

⚙️ خطای عجیب vMotion که هیچ نشونه استاندارد خرابی دیسک نداشت
◀️ تو مقاله‌های Broadcom یه سناریوی جالب هست که خیلی از ادمین‌های vSAN باهاش گیج می‌شن: عملیات vMotion شکست می‌خوره و تو لاگ vmkwarning پیام خطای Checksum از LSOM دیده می‌شه (CRC محاسبه‌شده با CRC ذخیره‌شده مطابقت نداره).

◀️ نکته عجیب اینجاست که هیچکدوم از نشونه‌های معمول خرابی دیسک دیده نمی‌شه: نه SCSI Sense Code، نه Permanent Device Loss، نه حتی گزارشی که نشون بده I/O جدید داره تو مسیر خراب می‌شه. یعنی هرکسی که فقط دنبال خطای استاندارد دیسک بگرده، هیچی پیدا نمی‌کنه.

◀️ ریشه ماجرا هم چیز غیرمنتظره‌ایه: خود دیسک‌ها کاملاً سالمن، ولی افت سیگنال فیزیکی تو Backplane یا کابل‌های SAS باعث می‌شه داده موقع عبور از این مسیر دچار تداخل بشه و وقتی LSOM داره Checksum رو چک می‌کنه، عدم تطابق پیدا کنه.

◀️ چون کنترلر دیسک اصلاً متوجه این تداخل سیگنال نمی‌شه، هیچ خطای استاندارد SCSI هم ثبت نمی‌کنه؛ یعنی مشکل درست از جایی میاد که هیچ ابزار مانیتورینگ معمولی بهش نگاه نمی‌کنه.
✅ راه‌حل واقعی، عیب‌یابی سخت‌افزاری کابل‌های SAS و Backplane با تولیدکننده سرور و تعویض قطعه معیوبه، نه هیچ تنظیم نرم‌افزاری. اگه تو محیط vSAN با خطای Checksum عجیب و بدون علامت واضح خرابی دیسک مواجه شدید، مستقیم برید سراغ لایه فیزیکی.
#VMware #vSAN #Troubleshooting #نکته_فنی
📱 @Abrplusdocs

t.me/abrplusdocs

🕵️ کمپینی که هزاران هایپروایزر ESXi رو با یه باگ دو‌ساله زمین‌گیر کرد

◀️ فوریه ۲۰۲۳، یه کمپین باج‌افزاری به اسم ESXiArgs شروع شد که به‌جای هدف قرار دادن یه کامپیوتر تک، مستقیم سراغ خود هایپروایزرهای ESXi رفت — یعنی یه حمله، همزمان چندین ماشین مجازی رو از کار می‌انداخت.
◀️ نکته تلخ ماجرا اینه که مهاجم‌ها از هیچ حفره روز صفرمی استفاده نکردن؛ آسیب‌پذیری CVE-2021-21974 تو سرویس OpenSLP بود که پچش از فوریه ۲۰۲۱ موجود بود، یعنی دقیقاً دو سال قبل از شروع حمله.
◀️ با این حال، تحقیقات Rapid7 نشون داد که بیش از ۱۸ هزار سرور ESXi روی اینترنت هنوز آسیب‌پذیر و در معرض دید بودن. نتیجه؟ طبق گزارش CISA و FBI، بیش از ۳۸۰۰ سرور در سراسر دنیا (بیشترین آسیب در اروپا) واقعاً آلوده شدن.
◀️ نکته جالب اینه که از دید مهاجم‌ها، این کمپین چندان هم موفق نبود؛ چون CISA و محقق‌های امنیتی اسکریپت‌های رایگان منتشر کردن و اکثر قربانی‌ها به‌جای پرداخت باج، از همون اسکریپت‌ها استفاده کردن.

✅ درسی که این ماجرا برای هر ادمین ESXi داره مشخصه: وقتی یه باگ رو تو هایپروایزر پچ نمی‌کنید، ریسک دیگه محدود به یه VM نیست، کل کلاسترت رو هواس

#تاریخچه_هک #VMware #ESXi #Ransomware #CloudSecurity

📱 @Abrplusdocs
t.me/abrplusdocs

🔵 دو سال بعد از برادکام: نه مهاجرت دسته‌جمعی، نه بازگشت به روال عادی

◀️ یه نظرسنجی تازه از CloudBolt (فوریه ۲۰۲۶، در آمریکای شمالی) نشون می‌ده: ۸۶ درصد سازمان‌ها دارن به‌طور فعال ردپای VMware رو تو زیرساخت‌شون کم می‌کنن، ولی فقط ۴ درصد کامل مهاجرت کردن.
◀️ یعنی اکثریت دارن مسیر تدریجی رو انتخاب می‌کنن، نه تعویض یک‌شبه؛ چیزی که با گزارش دیگه‌ای از سایت OpenStack هم هم‌خوانی داره: طبق تحقیق Civo، چهل و هشت درصد کاربرای فعلی یا سابق VMware الان برای همون امکانات قبلی، پول بیشتری می‌دن نزدیک نیمی از اونا هزینه‌شون دقیقاً دو برابر شده.
◀️ نکته جالب اینه که مقصد این مهاجرت‌ها هم یکسان نیست. OpenStack با پشتیبانی OpenInfra Foundation و توزیع‌هایی مثل Canonical و Mirantis، مقصد اصلی سازمان‌های بزرگ‌تر و Telco هاست، در حالی که Proxmox بیشتر تو سازمان‌های کوچیک و متوسط جا افتاده، مخصوصاً بعد از عرضه Proxmox Datacenter Manager که مشکل مدیریت چندکلاستری (رقیب vCenter) رو حل کرد.
◀️ نکته : طبق گفته OpenInfra، با ابزارهای جدید، مهاجرت مستقیم یه VM از VMware به OpenStack الان فقط چند ثانیه طول می‌کشه، نه هفته‌ها پروژه.

✅ نظر شخصی من اینه که تصمیم واقعی دیگه بین موندن یا مهاجرت کردن نیست؛ بین «یه استک واحد» یا «چند استک موازی» (VMware برای Workload های Stateful حساس، OpenStack یا Proxmox برای بقیه) هست. کسایی که این تصمیم رو عقب بندازن، دقیقاً همونایی هستن که تو نظرسنجی‌های بعدی جزو اون ۸۶ درصد «هنوز داریم فکر می‌کنیم» می‌مونن.

#OpenStack #VMware #Broadcom #تحلیل #CloudSecurity

📱 @Abrplusdocs
t.me/abrplusdocs

📍ساعت‌ کاری جدید ادارات از اول مهر تا آخر سال اعلام شد: فعالیت از ۸ تا ۱۳