وقتی 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 ☁️
در این مقاله، تیم 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 ☁️
Ubicloud
Virtualizing NVidia HGX B200 GPUs with Open Source
This blog post covers how we virtualized NVIDIA HGX B200 GPUs using open-source software. It talks about VFIO passthrough, QEMU PCI topology fixes, large BAR boot stalls, and Fabric Manager partitions.
❤3👍2
اختلال برق در 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 ☁️
توی این ایمیل که در لیست 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 ☁️
❤4
وقتی پای 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 ☁️
خیلیها فکر میکنن 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 ☁️
pierce.dev
Go ahead, self-host Postgres | Pierce Freeman
Self-hosting Postgres is simpler and cheaper than managed services suggest, with comparable reliability and better performance tunability.
❤5
وقتی آیندهی رایانش کوانتومی جدیتر از همیشه میشه
در آخرین پست بلاگ Scott Aaronson، بحث درباره اینه که چقدر احتمال داره تا چند سال آینده رایانش کوانتومی مفید و fault-tolerant واقعاً محقق بشه، یعنی ماشینی که بتونه الگوریتمهایی مثل Shor رو با خطاهای مدیریتشده اجرا کنه. بعد از شرکت در کنفرانس Q2B و دیدن پیشرفتهای واقعی در سختافزار (مثل سیستمهای Ion-trap، QuEra، Quantinuum و چیپهای Google/IBM)، دیدگاهش نسبت به «آیندهی نزدیک» کوانتوم بیشتر مثبت شده، هرچند هنوز نمیدونه دقیقاً کی این اتفاق میافته. از نظرش در ۲۰۲۵، برخی پلتفرمها به فیدلیتی بالای 99.9٪ رسیدهان، سطحی که آستانهی fault-tolerance رو امکانپذیر میکنه.
در یک مصاحبهی مرتبط با موضوع نیز به این نکته اشاره شد که اگر قبل از انتخابات ریاستجمهوری ۲۰۲۸، یک کامپیوتر کوانتومی fault-tolerant بتونه حتی کاری ساده مثل فاکتور کردن عدد ۱۵ با الگوریتم Shor انجام بده، اون رو «احتمال زنده» میدونه نه قطعیت، بلکه چیزی مثل “نه مطمئنم نمیشه”.
نویسنده همچنین بین دو نوع شرکتها تفکیک قائل شده:
۱. گروهی که واقعاً روی مشکلات علمی واقعی کار میکنن
۲. گروهی که فقط روایتهای جذاب برای سرمایهگذاران و دولتها میسازن بدون اینکه لزوماً پیشرفت فنی پشتش باشه.
در پایان، تاکید میکنه که هنوز برنامهها و کاربردهای واقعی کوانتومی محدود به حوزههایی مثل شبیهسازی فیزیک/شیمی، شکستن رمزنگاری فعلی، و در آینده کاربردهای بهینهسازی هستن، اما مسیر برای دیدن اینها تا چند سال آینده کوتاهتر از گذشته به نظر میرسه.
منبع:
scottaaronson.blog
@NobarCloud ☁️
در آخرین پست بلاگ Scott Aaronson، بحث درباره اینه که چقدر احتمال داره تا چند سال آینده رایانش کوانتومی مفید و fault-tolerant واقعاً محقق بشه، یعنی ماشینی که بتونه الگوریتمهایی مثل Shor رو با خطاهای مدیریتشده اجرا کنه. بعد از شرکت در کنفرانس Q2B و دیدن پیشرفتهای واقعی در سختافزار (مثل سیستمهای Ion-trap، QuEra، Quantinuum و چیپهای Google/IBM)، دیدگاهش نسبت به «آیندهی نزدیک» کوانتوم بیشتر مثبت شده، هرچند هنوز نمیدونه دقیقاً کی این اتفاق میافته. از نظرش در ۲۰۲۵، برخی پلتفرمها به فیدلیتی بالای 99.9٪ رسیدهان، سطحی که آستانهی fault-tolerance رو امکانپذیر میکنه.
در یک مصاحبهی مرتبط با موضوع نیز به این نکته اشاره شد که اگر قبل از انتخابات ریاستجمهوری ۲۰۲۸، یک کامپیوتر کوانتومی fault-tolerant بتونه حتی کاری ساده مثل فاکتور کردن عدد ۱۵ با الگوریتم Shor انجام بده، اون رو «احتمال زنده» میدونه نه قطعیت، بلکه چیزی مثل “نه مطمئنم نمیشه”.
نویسنده همچنین بین دو نوع شرکتها تفکیک قائل شده:
۱. گروهی که واقعاً روی مشکلات علمی واقعی کار میکنن
۲. گروهی که فقط روایتهای جذاب برای سرمایهگذاران و دولتها میسازن بدون اینکه لزوماً پیشرفت فنی پشتش باشه.
در پایان، تاکید میکنه که هنوز برنامهها و کاربردهای واقعی کوانتومی محدود به حوزههایی مثل شبیهسازی فیزیک/شیمی، شکستن رمزنگاری فعلی، و در آینده کاربردهای بهینهسازی هستن، اما مسیر برای دیدن اینها تا چند سال آینده کوتاهتر از گذشته به نظر میرسه.
منبع:
scottaaronson.blog
@NobarCloud ☁️
Shtetl-Optimized
More on whether useful quantum computing is “imminent”
These days, the most common question I get goes something like this: A decade ago, you told people that scalable quantum computing wasn’t imminent. Now, though, you claim it plausibly is immi…
🔥6
وقتی دیتابیسها باید برای 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 ☁️
توی این پست، 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 ☁️
👍7
مایکروسافت بالاخره بعد از سالها پشتیبانی Native از NVMe رو به ویندوز آورد
ویژگیای که قبلاً فقط تو Windows Server 2025 بود و باعث افزایش چشمگیر کارایی SSD میشد.
تا قبل از این، ویندوز برای SSDهای NVMe از یه مدل قدیمی استفاده میکرد که دستورات NVMe رو از طریق SCSI تبدیل میکرد و باعث میشد سرعت واقعی SSDها گرفته بشه.
اما با معرفی درایور Native NVMe، سیستمعامل میتونه مستقیم با SSDهای NVMe صحبت کنه، latency رو کم و throughput رو بالا ببره. بعضی کاربران با استفاده از تغییرات رجیستری تونستن این قابلیت رو در ویندوز 11 نسخه 25H2 فعال کنن، بدون نیاز به ابزار جانبی. نتایج بنچمارکها نشون داده که سرعت کارهای تصادفی (Random I/O) تا ۸۵٪ افزایش پیدا کرده، مخصوصاً در نوشتن ۴K روی SSDهای سریع.
البته نکته اینه که:
مایکروسافت فعلاً این ویژگی رو رسمی برای ویندوز 11 منتشر نکرده
ممکنه ابزارهای مدیریت SSD (مثل مدیریت برندها) بعد از فعالکردن درایور جدید رفتار عجیبی داشته باشن و هک رجیستری ریسکهایی مثل ناسازگاری یا کرش سیستم داره.
برای کاربرهای معمولی شاید افزایش سرعت محسوس نباشه، اما این قدم فنی میتونه توی سرورهای ابری، پایگاهداده و بارهای سنگین I/O واقعاً کاربردی باشه.
منبع
@NobarCloud ☁️
ویژگیای که قبلاً فقط تو Windows Server 2025 بود و باعث افزایش چشمگیر کارایی SSD میشد.
تا قبل از این، ویندوز برای SSDهای NVMe از یه مدل قدیمی استفاده میکرد که دستورات NVMe رو از طریق SCSI تبدیل میکرد و باعث میشد سرعت واقعی SSDها گرفته بشه.
اما با معرفی درایور Native NVMe، سیستمعامل میتونه مستقیم با SSDهای NVMe صحبت کنه، latency رو کم و throughput رو بالا ببره. بعضی کاربران با استفاده از تغییرات رجیستری تونستن این قابلیت رو در ویندوز 11 نسخه 25H2 فعال کنن، بدون نیاز به ابزار جانبی. نتایج بنچمارکها نشون داده که سرعت کارهای تصادفی (Random I/O) تا ۸۵٪ افزایش پیدا کرده، مخصوصاً در نوشتن ۴K روی SSDهای سریع.
البته نکته اینه که:
مایکروسافت فعلاً این ویژگی رو رسمی برای ویندوز 11 منتشر نکرده
ممکنه ابزارهای مدیریت SSD (مثل مدیریت برندها) بعد از فعالکردن درایور جدید رفتار عجیبی داشته باشن و هک رجیستری ریسکهایی مثل ناسازگاری یا کرش سیستم داره.
برای کاربرهای معمولی شاید افزایش سرعت محسوس نباشه، اما این قدم فنی میتونه توی سرورهای ابری، پایگاهداده و بارهای سنگین I/O واقعاً کاربردی باشه.
منبع
@NobarCloud ☁️
Tom's Hardware
Windows 11 rockets SSD performance to new heights with hacked native NVMe driver — up to 85% higher random workload performance…
Three registry entries to boost NVMe performance for free
❤3👌1
وقتی وب از یه پروژهی علمی شروع شد🔥
سال ۱۹۸۹، Tim Berners-Lee دانشمند بریتانیایی که در آزمایشگاه CERN سوئیس کار میکرد، ایدهای برای اشتراکگذاری آسان اطلاعات بین رایانهها داد، ایدهی جهانی که بعدها به World Wide Web تبدیل شد. تا پایان سال ۱۹۹۰، اون و تیمش موفق شدن اولین وبسرور و همچنین وبکلاینت (مرورگر) رو روی کامپیوتر NeXT راهاندازی کنن. این سرور اولین صفحات وب رو با پروتکل HTTP و نشانیهای URL سرو میکرد.
آدرس اولین وبسایت دنیا هم info.cern.ch بود، که در ابتدا محتوای پروژهی Web و آموزش دربارهی HTML و HTTP رو نمایش میداد. در سال ۱۹۹۱ این وبسایت بهصورت عمومی منتشر شد و کمکم استفاده از Web رشد کرد.
تصمیم تاریخی بزرگ این بود که CERN در آوریل ۱۹۹۳ کل فناوری وب را بهصورت رایگان و بدون حق امتیاز در اختیار همه قرار داد، همان چیزی که مسیر انفجاری اینترنت مدرن را هموار کرد.
به این ترتیب از اون ایدهی ساده برای بهاشتراکگذاری اطلاعات در یک آزمایشگاه علمی، شبکهای جهانی بهوجود آمد که امروز میلیاردها نفر و خدمات به آن تکیه دارند.
منبع:
The Silicon Underground: The First Web Server
@NobarCloud ☁️
سال ۱۹۸۹، Tim Berners-Lee دانشمند بریتانیایی که در آزمایشگاه CERN سوئیس کار میکرد، ایدهای برای اشتراکگذاری آسان اطلاعات بین رایانهها داد، ایدهی جهانی که بعدها به World Wide Web تبدیل شد. تا پایان سال ۱۹۹۰، اون و تیمش موفق شدن اولین وبسرور و همچنین وبکلاینت (مرورگر) رو روی کامپیوتر NeXT راهاندازی کنن. این سرور اولین صفحات وب رو با پروتکل HTTP و نشانیهای URL سرو میکرد.
آدرس اولین وبسایت دنیا هم info.cern.ch بود، که در ابتدا محتوای پروژهی Web و آموزش دربارهی HTML و HTTP رو نمایش میداد. در سال ۱۹۹۱ این وبسایت بهصورت عمومی منتشر شد و کمکم استفاده از Web رشد کرد.
تصمیم تاریخی بزرگ این بود که CERN در آوریل ۱۹۹۳ کل فناوری وب را بهصورت رایگان و بدون حق امتیاز در اختیار همه قرار داد، همان چیزی که مسیر انفجاری اینترنت مدرن را هموار کرد.
به این ترتیب از اون ایدهی ساده برای بهاشتراکگذاری اطلاعات در یک آزمایشگاه علمی، شبکهای جهانی بهوجود آمد که امروز میلیاردها نفر و خدمات به آن تکیه دارند.
منبع:
The Silicon Underground: The First Web Server
@NobarCloud ☁️
❤🔥4
وقتی بفهمی یه پروسه چرا توی لینوکست اجرا شده
یه ابزار جدید و خیلی کاربردی با اسم witr (کوتاه شدهی ?Why Is This Running) برای لینوکس منتشر شده که بهت کمک میکنه دلیل اجرا شدن یک پروسه، سرویس یا پورت رو سریع بفهمی. بهجای اینکه چند تا ابزار مستقل مثل ps، top، lsof یا ss رو جداگانه اجرا کنی و اطلاعات رو دستی کنار هم بذاری، witr این کار رو یکجا و بهصورت داستانی توضیح میده:
این پروسه چیه؟
از کجا شروع شده؟
چه چیزی باعث ادامهی اجرای اون شده؟
در چه کانتکستی (مثل systemd، container، shell، cron) اجرا شده؟
این ابزار هدفش اینه که وقتی SSH زدی به یه سرور و دیدی یه چیز عجیب داره اجرا میشه، سریع بدونی چرا اونجاست بدون اینکه کلی وقت صرف تحلیل خروجی چند ابزار بکنی.
ویژگیهای اصلی ابزار:
۱. توضیح دلیل وجود یک PID به صورت زنجیرهی مسئولیت (causal chain)
۲. پشتیبانی از نام پروسه، PID یا حتی پورت برای Query کردن
۳. خروجی انسانیخوان و قابل استفاده حتی تحت فشار دیباگ
۴. گزینهی خروجی JSON برای اتوماسیون یا ابزارهای دیگر
بهعبارتی، این ابزار نه جایگزین مانیتورینگ میشه و نه ابزارهای پروفایلینگ، بلکه برای مواقعی طراحی شده که سریع باید بفهمی چرا این داره اجرا میشه؟ مخصوصاً وقتی توی سرور تحت فشار هستی.
منبع:
GitHub, pranshuparmar/witr: Why Is This Running
@NobarCloud ☁️
یه ابزار جدید و خیلی کاربردی با اسم witr (کوتاه شدهی ?Why Is This Running) برای لینوکس منتشر شده که بهت کمک میکنه دلیل اجرا شدن یک پروسه، سرویس یا پورت رو سریع بفهمی. بهجای اینکه چند تا ابزار مستقل مثل ps، top، lsof یا ss رو جداگانه اجرا کنی و اطلاعات رو دستی کنار هم بذاری، witr این کار رو یکجا و بهصورت داستانی توضیح میده:
این پروسه چیه؟
از کجا شروع شده؟
چه چیزی باعث ادامهی اجرای اون شده؟
در چه کانتکستی (مثل systemd، container، shell، cron) اجرا شده؟
این ابزار هدفش اینه که وقتی SSH زدی به یه سرور و دیدی یه چیز عجیب داره اجرا میشه، سریع بدونی چرا اونجاست بدون اینکه کلی وقت صرف تحلیل خروجی چند ابزار بکنی.
ویژگیهای اصلی ابزار:
۱. توضیح دلیل وجود یک PID به صورت زنجیرهی مسئولیت (causal chain)
۲. پشتیبانی از نام پروسه، PID یا حتی پورت برای Query کردن
۳. خروجی انسانیخوان و قابل استفاده حتی تحت فشار دیباگ
۴. گزینهی خروجی JSON برای اتوماسیون یا ابزارهای دیگر
بهعبارتی، این ابزار نه جایگزین مانیتورینگ میشه و نه ابزارهای پروفایلینگ، بلکه برای مواقعی طراحی شده که سریع باید بفهمی چرا این داره اجرا میشه؟ مخصوصاً وقتی توی سرور تحت فشار هستی.
منبع:
GitHub, pranshuparmar/witr: Why Is This Running
@NobarCloud ☁️
GitHub
GitHub - pranshuparmar/witr: Why is this running?
Why is this running? Contribute to pranshuparmar/witr development by creating an account on GitHub.
❤6👏1
وقتی میخوای یه OpenStack واقعی رو توی محیط توسعه راه بندازی🔥
ابزار DevStack یه مجموعه اسکریپت و ابزار کاربردیه که بهت اجازه میده بدون دردسر و سریع یه ابر OpenStack کامل روی ماشین یا VM خودت راهاندازی کنی. مخصوص توسعه، تست و یادگیری.
این ابزار از سورسهای رسمی OpenStack میسازه و بهت کمک میکنه تا:
۱. تو یه محیط ایزوله و تمیز (مثلاً VM) سریع یه ابر توسعه بسازی،
۲. بفهمی کدهای مختلف OpenStack چطور کنار هم کار میکنن،
۳. ویژگیهای جدید یا پروتوتایپهای بین پروژهای رو امتحان کنی.
همچنین DevStack برای توسعهدهندهها و مشارکتکنندههای OpenStack عالیه چون بهشون محیطی میده که همه سرویسها (مثلاً compute، networking، storage و dashboard) رو کنار هم ببینن و تست کنن. برای شروع معمولاً کافیه DevStack رو از مخزن Git کلون کنی و با اجرای دستور stack.sh/. تو یه VM تمیز، سرویس OpenStack رو بالا بیاری. در نتیجه میتونی بهسادگی به داشبورد مثل Horizon و APIهای OpenStack دسترسی داشته باشی.
نکته مهم اینه که DevStack برای محیطهای production نیست، بلکه ابزاریه برای توسعه، تست و نمونهسازی سریع. اگر میخوای OpenStack رو در مقیاس واقعی و در محیط ابری یا دیتاسنتر مستقر کنی، باید از ابزارهای رسمی و پروسههای استاندارد استفاده کنی.
منبع:
Devstack
@NobarCloud ☁️
ابزار DevStack یه مجموعه اسکریپت و ابزار کاربردیه که بهت اجازه میده بدون دردسر و سریع یه ابر OpenStack کامل روی ماشین یا VM خودت راهاندازی کنی. مخصوص توسعه، تست و یادگیری.
این ابزار از سورسهای رسمی OpenStack میسازه و بهت کمک میکنه تا:
۱. تو یه محیط ایزوله و تمیز (مثلاً VM) سریع یه ابر توسعه بسازی،
۲. بفهمی کدهای مختلف OpenStack چطور کنار هم کار میکنن،
۳. ویژگیهای جدید یا پروتوتایپهای بین پروژهای رو امتحان کنی.
همچنین DevStack برای توسعهدهندهها و مشارکتکنندههای OpenStack عالیه چون بهشون محیطی میده که همه سرویسها (مثلاً compute، networking، storage و dashboard) رو کنار هم ببینن و تست کنن. برای شروع معمولاً کافیه DevStack رو از مخزن Git کلون کنی و با اجرای دستور stack.sh/. تو یه VM تمیز، سرویس OpenStack رو بالا بیاری. در نتیجه میتونی بهسادگی به داشبورد مثل Horizon و APIهای OpenStack دسترسی داشته باشی.
نکته مهم اینه که DevStack برای محیطهای production نیست، بلکه ابزاریه برای توسعه، تست و نمونهسازی سریع. اگر میخوای OpenStack رو در مقیاس واقعی و در محیط ابری یا دیتاسنتر مستقر کنی، باید از ابزارهای رسمی و پروسههای استاندارد استفاده کنی.
منبع:
Devstack
@NobarCloud ☁️
OpenDev: Free Software Needs Free Tools
devstack
System for quickly installing an OpenStack cloud from upstream git for testing and development.
🔥2
اطلاعیه رسمی | همکاری نوبرکلاد و پچیم
با افتخار اعلام میکنیم که نوبرکلاد در همکاری جدید خود با پچیم، خدمات سرور و زیرساخت ابری را در اختیار کاربران این پلتفرم قرار میدهد.
از این پس، کاربران پچیم میتوانند مستقیماً از طریق پنل کاربری خود، در صورت نیاز به سرور، به پلنهای متنوع نوبرکلاد دسترسی داشته باشند و متناسب با نیازشان بهترین گزینه را تنظیم و انتخاب کنند. همچنین میتوانید از مزایا و خدمات پچیم هم استفاده کنید.
این همکاری با هدف سادهسازی فرآیند تهیه سرور، افزایش کیفیت خدمات زیرساختی و بهبود تجربه کاربران شکل گرفته و ما در نوبرکلاد، از این همکاری ارزشمند بسیار خرسندیم.
1. بررسی پلنها
2. دسترسی مستقیم از پنل پچیم
3. زیرساخت پایدار و حرفهای نوبرکلاد
به آیندهای سریعتر و پایدارتر فکر میکنیم🚀
@NobarCloud ☁️
با افتخار اعلام میکنیم که نوبرکلاد در همکاری جدید خود با پچیم، خدمات سرور و زیرساخت ابری را در اختیار کاربران این پلتفرم قرار میدهد.
از این پس، کاربران پچیم میتوانند مستقیماً از طریق پنل کاربری خود، در صورت نیاز به سرور، به پلنهای متنوع نوبرکلاد دسترسی داشته باشند و متناسب با نیازشان بهترین گزینه را تنظیم و انتخاب کنند. همچنین میتوانید از مزایا و خدمات پچیم هم استفاده کنید.
این همکاری با هدف سادهسازی فرآیند تهیه سرور، افزایش کیفیت خدمات زیرساختی و بهبود تجربه کاربران شکل گرفته و ما در نوبرکلاد، از این همکاری ارزشمند بسیار خرسندیم.
1. بررسی پلنها
2. دسترسی مستقیم از پنل پچیم
3. زیرساخت پایدار و حرفهای نوبرکلاد
به آیندهای سریعتر و پایدارتر فکر میکنیم🚀
@NobarCloud ☁️
Telegram
Pachim|پچیم
🎉 خبر خوب برای کاربرای پچیم
میتونی مستقیم از خود پچیم سرور داخلی و خارجی بخری و
🎁 روی هر سروری که از طریق پچیم فعال کنی، ⡔⠎⠸⣁⣄⠰⣄ ⢔⠸⠰ ⡤⡰⠨⢉⠓⢂⠆ ⢘⠌⡉⠥ ⠓⡰ ⡢⠖⠖⠜ ⡡⣐⢃⠍ ⢑⢊⢐⢉ فعال میشه تا راحت دیپلوی، مانیتورینگ و بکاپ رو یهجا داشته باشی.
✅ سرور مجازی با آیپی…
میتونی مستقیم از خود پچیم سرور داخلی و خارجی بخری و
🎁 روی هر سروری که از طریق پچیم فعال کنی، ⡔⠎⠸⣁⣄⠰⣄ ⢔⠸⠰ ⡤⡰⠨⢉⠓⢂⠆ ⢘⠌⡉⠥ ⠓⡰ ⡢⠖⠖⠜ ⡡⣐⢃⠍ ⢑⢊⢐⢉ فعال میشه تا راحت دیپلوی، مانیتورینگ و بکاپ رو یهجا داشته باشی.
✅ سرور مجازی با آیپی…
❤🔥3
وقتی معماری نرمافزار باید با زیرساخت ابری هماهنگ باشه
رویکرد طراحی دامنهمحور یا همون Domain-Driven Design (DDD) فقط درباره نوشتن کد تمیز نیست؛ یه روش فکر کردنه برای ساخت سیستمهایی که منطق کسبوکارشون شفاف، قابل توسعه و همراستا با معماریهای ابری و توزیعشده باشه. در معماریهای مدرن مثل میکروسرویس و سیستمهای Cloud-Native، سرویسها معمولاً بر اساس مرزهای مشخص دامنه از هم جدا میشن. این همون جاییه که مفاهیمی مثل Bounded Context توی DDD، بهصورت طبیعی تبدیل میشن به مرز سرویسها، دیتابیسها و حتی استراتژیهای استقرار روی کلاود.
این مخزن گیتهاب یه نقطه شروع کاربردی برای یادگیری DDD با نگاه زیرساختیه و کمک میکنه:
۱. قبل از انتخاب ابزار و پلتفرم ابری، دامنه رو درست مدلسازی کنی
۲. سرویسها رو طوری طراحی کنی که مستقل Deploy و Scale بشن
۳. پیچیدگی سیستمهای توزیعشده رو با Event، Aggregate و Context Map کنترل کنی
۴. معماریای بسازی که با رشد سیستم، دچار Coupling و بینظمی نشه.
منابع این مجموعه شامل مقاله، کتاب، ویدیو و ابزارهاییه که برای معمار نرمافزار، بکاند و تیمهای زیرساخت و کلاود کاملاً کاربردیه.
اگه قراره سیستم روی کلاد رشد کنه، طراحی دامنهمحور کمک میکنه زیرساخت در خدمت منطق سیستم باشه، نه برعکس.
منبع:
📌 https://github.com/heynickc/awesome-ddd
@NobarCloud ☁️
رویکرد طراحی دامنهمحور یا همون Domain-Driven Design (DDD) فقط درباره نوشتن کد تمیز نیست؛ یه روش فکر کردنه برای ساخت سیستمهایی که منطق کسبوکارشون شفاف، قابل توسعه و همراستا با معماریهای ابری و توزیعشده باشه. در معماریهای مدرن مثل میکروسرویس و سیستمهای Cloud-Native، سرویسها معمولاً بر اساس مرزهای مشخص دامنه از هم جدا میشن. این همون جاییه که مفاهیمی مثل Bounded Context توی DDD، بهصورت طبیعی تبدیل میشن به مرز سرویسها، دیتابیسها و حتی استراتژیهای استقرار روی کلاود.
این مخزن گیتهاب یه نقطه شروع کاربردی برای یادگیری DDD با نگاه زیرساختیه و کمک میکنه:
۱. قبل از انتخاب ابزار و پلتفرم ابری، دامنه رو درست مدلسازی کنی
۲. سرویسها رو طوری طراحی کنی که مستقل Deploy و Scale بشن
۳. پیچیدگی سیستمهای توزیعشده رو با Event، Aggregate و Context Map کنترل کنی
۴. معماریای بسازی که با رشد سیستم، دچار Coupling و بینظمی نشه.
منابع این مجموعه شامل مقاله، کتاب، ویدیو و ابزارهاییه که برای معمار نرمافزار، بکاند و تیمهای زیرساخت و کلاود کاملاً کاربردیه.
اگه قراره سیستم روی کلاد رشد کنه، طراحی دامنهمحور کمک میکنه زیرساخت در خدمت منطق سیستم باشه، نه برعکس.
منبع:
📌 https://github.com/heynickc/awesome-ddd
@NobarCloud ☁️
GitHub
GitHub - heynickc/awesome-ddd: A curated list of Domain-Driven Design (DDD), Command Query Responsibility Segregation (CQRS), Event…
A curated list of Domain-Driven Design (DDD), Command Query Responsibility Segregation (CQRS), Event Sourcing, and Event Storming resources - heynickc/awesome-ddd
👌3
یکی از سوءتفاهمهای رایج در کار با دیتابیس MySQL در زیرساختهای مدرن
یک تصور اشتباه اینه که دادهها در MySQL مستقیماً روی دیسک نوشته و از همونجا خونده میشن، در حالی که این دیتابیس برای حفظ پرفورمنس از یک مسیر چندلایه و بهینهشده برای اجرای کوئریها استفاده میکنه.
در پشت صحنه، قبل از درگیر شدن دیسک، اجزایی مثل:
۱. ساختارهای In-Memory
۲. موارد Buffer Pool و Cache
۳. بهینهساز کوئری و Execution Plan
نقش اصلی رو در پاسخدهی سریع ایفا میکنن و دیسک بیشتر بهعنوان لایه پایداری داده استفاده میشه. در محیطهای ابری، این موضوع اهمیت بیشتری پیدا میکنه؛ چون معمولاً:
استوریجها شبکهمحور هستن، تأخیر دیسک متغیره و مقیاسپذیری بدون شناخت رفتار حافظه، عملاً بیاثر میشه.
اگر جریان اجرای کوئری در MySQL بهدرستی درک نشه، انتخاب Instance مناسب، تنظیم منابع، Autoscaling و حتی معماری دیتابیس میتونه کاملاً اشتباه انجام بشه.
در این مقاله، مسیر اجرای یک کوئری MySQL بهصورت ساده و مرحلهبهمرحله توضیح داده شده و مشخص میکنه:
۱. پردازش کوئری از کجا شروع میشه
۲. چه زمانی از حافظه استفاده میشه
۳.در چه مرحلهای دسترسی به Storage انجام میگیره
برای افرادی که روی دیتابیسهای ابری، زیرساخت، DevOps یا سیستمهای مقیاسپذیر کار میکنن، فهم این جریان یکی از پایههای تصمیمگیری درست محسوب میشه.
منبع:
https://farshadth.medium.com/how-mysql-works-behind-the-scenes-72746950cd65
@NobarCloud ☁️
یک تصور اشتباه اینه که دادهها در MySQL مستقیماً روی دیسک نوشته و از همونجا خونده میشن، در حالی که این دیتابیس برای حفظ پرفورمنس از یک مسیر چندلایه و بهینهشده برای اجرای کوئریها استفاده میکنه.
در پشت صحنه، قبل از درگیر شدن دیسک، اجزایی مثل:
۱. ساختارهای In-Memory
۲. موارد Buffer Pool و Cache
۳. بهینهساز کوئری و Execution Plan
نقش اصلی رو در پاسخدهی سریع ایفا میکنن و دیسک بیشتر بهعنوان لایه پایداری داده استفاده میشه. در محیطهای ابری، این موضوع اهمیت بیشتری پیدا میکنه؛ چون معمولاً:
استوریجها شبکهمحور هستن، تأخیر دیسک متغیره و مقیاسپذیری بدون شناخت رفتار حافظه، عملاً بیاثر میشه.
اگر جریان اجرای کوئری در MySQL بهدرستی درک نشه، انتخاب Instance مناسب، تنظیم منابع، Autoscaling و حتی معماری دیتابیس میتونه کاملاً اشتباه انجام بشه.
در این مقاله، مسیر اجرای یک کوئری MySQL بهصورت ساده و مرحلهبهمرحله توضیح داده شده و مشخص میکنه:
۱. پردازش کوئری از کجا شروع میشه
۲. چه زمانی از حافظه استفاده میشه
۳.در چه مرحلهای دسترسی به Storage انجام میگیره
برای افرادی که روی دیتابیسهای ابری، زیرساخت، DevOps یا سیستمهای مقیاسپذیر کار میکنن، فهم این جریان یکی از پایههای تصمیمگیری درست محسوب میشه.
منبع:
https://farshadth.medium.com/how-mysql-works-behind-the-scenes-72746950cd65
@NobarCloud ☁️
Medium
How MySQL Works Behind the Scenes
Many people think MySQL always reads and writes data directly from disk, but in reality, it is designed to minimize disk access and…
🔥4
میرور(Mirror) دقیقاً چه کاری انجام میدهد؟
میرور به یک نسخهی کامل، مستقل و همگامشونده از یک منبع اصلی گفته میشود که هدف آن جایگزینی شفاف منبع upstream است، بدون اینکه تغییری در تنظیمات کلاینت ایجاد شود.
به بیان دقیقتر، میرور باید بتواند در صورت عدم دسترسی به منبع اصلی، همان دادهها را با همان ساختار و همان مسیرها ارائه دهد.
میرور دقیقاً چه چیزی را شامل میشود؟
میرور فقط شامل فایلها نیست. یک میرور معتبر باید:
۱. تمام بستهها یا مخازن را بهصورت کامل نگه دارد
۲. متادیتا (index، manifest، release file و …) را حفظ کند
۳. ساختار دایرکتوری upstream را بدون تغییر بازتولید کند
۴. بهصورت خودکار و دورهای همگامسازی شود
نکته مهم: اگر حتی یکی از این اجزا ناقص باشد، آن سرویس از نظر فنی «میرور» محسوب نمیشود.
تفاوت میرور با Cache و Proxy چیست؟
کش برای افزایش سرعت طراحی شده و دادهها را بهصورت موقت و ناقص نگه میدارد و پروکسی صرفاً مسیر عبور درخواستهاست و به منبع اصلی وابسته میماند اما میرور یک منبع مستقل است که میتواند حتی در نبود اتصال خارجی، سرویسدهی کامل انجام دهد.
میرور چرا در زیرساخت نرمافزار حیاتی است؟
در زیرساختهایی که وابسته به مخازن بسته هستند (مثل سیستمهای CI/CD)، نبود میرور باعث:
۱. ناپایداری بیلدها
۲. افزایش خطاهای غیرقابل پیشبینی
۳. وابستگی کامل به شبکهی خارجی
۴. همچنین میرور کنترل زنجیره تأمین نرمافزار در اختیار خود سیستم باشد
پروژه Mirava چه نقشی دارد؟
پروژه Mirava یک ابزار اجرایی نیست، بلکه یک مرجع ساختاریافته از میرورهای داخلی ایران معتبر است که وضعیت دسترسی و نوع سرویس هر میرور را مشخص میکند.
هدف این پروژه این است که مشخص شود:
۱. چه میرورهایی واقعاً وجود دارند
۲. هر کدام چه سرویسهایی را پوشش میدهند
۳. کدام میرورها فعال و قابل اتکا هستند
۴. داشتن میرور بهتنهایی کافی نیست؛ شناخت میرور قابل اعتماد اهمیت دارد.
نکته: میرور یک قابلیت جانبی نیست، بلکه یک مولفهی پایهای زیرساخت در کنار DNS و رجیستری بستهها محسوب میشود.
زیرساختی که میرور ندارد، ذاتاً شکننده و وابسته است
🔗 مخزن پروژه Mirava
@NobarCloud ☁️
میرور به یک نسخهی کامل، مستقل و همگامشونده از یک منبع اصلی گفته میشود که هدف آن جایگزینی شفاف منبع upstream است، بدون اینکه تغییری در تنظیمات کلاینت ایجاد شود.
به بیان دقیقتر، میرور باید بتواند در صورت عدم دسترسی به منبع اصلی، همان دادهها را با همان ساختار و همان مسیرها ارائه دهد.
میرور دقیقاً چه چیزی را شامل میشود؟
میرور فقط شامل فایلها نیست. یک میرور معتبر باید:
۱. تمام بستهها یا مخازن را بهصورت کامل نگه دارد
۲. متادیتا (index، manifest، release file و …) را حفظ کند
۳. ساختار دایرکتوری upstream را بدون تغییر بازتولید کند
۴. بهصورت خودکار و دورهای همگامسازی شود
نکته مهم: اگر حتی یکی از این اجزا ناقص باشد، آن سرویس از نظر فنی «میرور» محسوب نمیشود.
تفاوت میرور با Cache و Proxy چیست؟
کش برای افزایش سرعت طراحی شده و دادهها را بهصورت موقت و ناقص نگه میدارد و پروکسی صرفاً مسیر عبور درخواستهاست و به منبع اصلی وابسته میماند اما میرور یک منبع مستقل است که میتواند حتی در نبود اتصال خارجی، سرویسدهی کامل انجام دهد.
میرور چرا در زیرساخت نرمافزار حیاتی است؟
در زیرساختهایی که وابسته به مخازن بسته هستند (مثل سیستمهای CI/CD)، نبود میرور باعث:
۱. ناپایداری بیلدها
۲. افزایش خطاهای غیرقابل پیشبینی
۳. وابستگی کامل به شبکهی خارجی
۴. همچنین میرور کنترل زنجیره تأمین نرمافزار در اختیار خود سیستم باشد
پروژه Mirava چه نقشی دارد؟
پروژه Mirava یک ابزار اجرایی نیست، بلکه یک مرجع ساختاریافته از میرورهای داخلی ایران معتبر است که وضعیت دسترسی و نوع سرویس هر میرور را مشخص میکند.
هدف این پروژه این است که مشخص شود:
۱. چه میرورهایی واقعاً وجود دارند
۲. هر کدام چه سرویسهایی را پوشش میدهند
۳. کدام میرورها فعال و قابل اتکا هستند
۴. داشتن میرور بهتنهایی کافی نیست؛ شناخت میرور قابل اعتماد اهمیت دارد.
نکته: میرور یک قابلیت جانبی نیست، بلکه یک مولفهی پایهای زیرساخت در کنار DNS و رجیستری بستهها محسوب میشود.
زیرساختی که میرور ندارد، ذاتاً شکننده و وابسته است
🔗 مخزن پروژه Mirava
@NobarCloud ☁️
GitHub
GitHub - GeeDook/mirava: Mirava is a curated list of Iranian package mirrors, providing reliable and fast access to essential software…
Mirava is a curated list of Iranian package mirrors, providing reliable and fast access to essential software resources within Iran. - GeeDook/mirava
🙏2❤1