EN
→ بازگشت به خبرخوان
شمارهٔ ۰۴۱۷Internet Computer۳ دقیقه۴ منبع

پرسش ۳۲ ترابایتی در واقع درباره حاشیه اطمینان نودهای ICP است

نودهای اینترنت کامپیوتر به این دلیل به حدود ۳۲ ترابایت NVMe نیاز ندارند که وضعیت فعلی ساب‌نت‌ها همین مقدار فضا می‌گیرد. این ظرفیت بزرگ‌تر برای چک‌پوینت‌ها، تاریخچهٔ تغییرناپذیر وضعیت، فایل‌های overlay، همگام‌سازی، کارایی و مقابله با رشد فضای دیسک در بدترین شرایط است.

اشتراک‌گذاری
رایانه اینترنتی (ICP)
پرسش ۳۲ ترابایتی در واقع درباره حاشیه اطمینان نودهای ICP است
تصویر: تولید هوش مصنوعی

یک بحث تازه در انجمن اینترنت کامپیوتر پرسشی ساده اما مهم دربارهٔ زیرساخت مطرح کرده است: اگر وضعیت تکثیرشدهٔ یک ساب‌نت در مقیاس ترابایت باشد، چرا مشخصات سخت‌افزاری نودها به حدود ۳۲ ترابایت NVMe خام نیاز دارد؟

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

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

چک‌پوینت‌ها فقط snapshotهای منفرد نیستند

نودهای ICP به‌صورت دوره‌ای از وضعیت ساب‌نت چک‌پوینت‌های گواهی‌شده می‌سازند. مستندات توسعه‌دهندگان می‌گوید نودی که به یک ساب‌نت می‌پیوندد یا از خرابی بازمی‌گردد، می‌تواند یک چک‌پوینت را دریافت کند، مانیفست درخت Merkle آن را بررسی کند و فقط بلاک‌های پس از آن را دوباره اجرا کند. این روش از بازپخش کل تاریخچهٔ ساب‌نت جلوگیری می‌کند، اما به این معناست که دادهٔ چک‌پوینت باید نوشته، نگهداری، احراز و برای بازیابی آماده شود. مستندات همگام‌سازی وضعیت ICP

طراحی لایهٔ ذخیره‌سازی یک محدودیت دیگر هم دارد: چک‌پوینت جدید نمی‌تواند پیش از تکمیل و گواهی‌شدن، به‌سادگی روی آخرین چک‌پوینت گواهی‌شده نوشته شود. نسخهٔ قدیمی تا زمان ساخت نسخهٔ جدید همچنان اهمیت دارد. توضیح فنی DFINITY چرخه‌ای را شرح می‌دهد که از فایل‌های پایدار، دادهٔ موقت یا «tip» و تغییر نام اتمیک استفاده می‌کند.

وضعیت منطقی با فایل‌های فیزیکی یکسان نیست

لایهٔ ذخیره‌سازی اینترنت کامپیوتر از درخت‌های ادغام‌شوندهٔ لاگ‌محور استفاده می‌کند. تغییرات در فایل‌های overlay اضافی نوشته می‌شوند و چند نسخه از یک داده ممکن است تا زمان ادغام در پس‌زمینه هم‌زمان باقی بمانند. در این فاصله، ردپای فیزیکی می‌تواند از اندازهٔ منطقی وضعیت بیشتر باشد. همچنین ممکن است دادهٔ چک‌پوینت قدیمی و overlayهای جدید هم‌زمان وجود داشته باشند، زیرا تغییر دادن چک‌پوینت گواهی‌شده، تمامیت آن را تهدید می‌کند. توضیح فنی DFINITY دربارهٔ لایهٔ ذخیره‌سازی

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

فضای خالی، بخشی از قابلیت اطمینان است

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

بحث فنی انجمن پیامد عملی را روشن می‌کند: پر شدن دیسک می‌تواند عواقب جدی برای یک ساب‌نت داشته باشد. بنابراین هدف عملی «جا دادن وضعیت فعلی» نیست؛ هدف، ایمن ماندن در برابر هم‌پوشانی چک‌پوینت‌ها، نوشتن سنگین، بازیابی و پاک‌سازی دیرهنگام است.

چرا پنج درایو می‌تواند برای سرعت باشد

این بحث یک سوءبرداشت رایج را هم روشن می‌کند. RAID 0 داده را بین چند درایو پخش می‌کند و mirror نیست. در این معماری، چند NVMe می‌توانند توان عملیاتی تجمیعی و تأخیر کمتر برای ساخت چک‌پوینت، overlayها، hashing و دسترسی معمول به وضعیت فراهم کنند. در مقابل، خود RAID 0 افزونگی لازم برای خرابی درایو را فراهم نمی‌کند؛ بنابراین مدل قابلیت اطمینان نود به تکثیر در سطح ساب‌نت و سازوکارهای بازیابی پروتکل وابسته است.

یک بحث قدیمی‌تر در انجمن DFINITY افزایش فضای NVMe در دسترس را از ۳٫۲ ترابایت به ۳۲ ترابایت، هم‌زمان با افزایش ظرفیت ذخیره‌سازی ساب‌نت، ثبت کرده است. این سابقه از یک برداشت مهم پشتیبانی می‌کند: مجموعهٔ دیسک بزرگ‌تر بخشی از گذار ظرفیت و کارایی بوده است، نه نشانه‌ای که هر نود دائماً ۳۲ ترابایت دادهٔ زندهٔ کانسترها را نگه می‌دارد. بحث ظرفیت ذخیره‌سازی ساب‌نت

برای توسعه‌دهندگان ICP، نتیجه روشن است. محدودیت‌های ذخیره‌سازی کانستر ظرفیت قابل مشاهده برای برنامه را توصیف می‌کنند؛ مشخصات NVMe نود، بودجهٔ فیزیکی لازم برای حفظ، تبدیل، احراز و بازیابی وضعیت تکثیرشده را توصیف می‌کند. این دو عدد به هم مرتبط‌اند، اما قابل جایگزینی نیستند. حداقل پیکربندی سخت‌افزاری دقیق همچنان مسئله‌ای مهندسی برای پروتکل و مشخصات ارائه‌دهندگان نود است و این بحث عمومی به‌تنهایی آن را تعیین نمی‌کند.

برچسب‌هاInternet Computerزیرساخت ICPسخت‌افزار نودNVMe
منابع مستند۴ مرجع
  1. [۰۱]Why do nodes require so much storage?forum.dfinity.org ↗
  2. [۰۲]State synchronization | ICP Developer Docsdocs.internetcomputer.org ↗
  3. [۰۳]A Journey into Stellarator: Part 1medium.com ↗
  4. [۰۴]Increasing subnet storage capacity and introducing resource reservation mechanismforum.dfinity.org ↗
خواندنی بعدی

خبرخوان را در ایمیل بگیرید

هر سیگنال تازه، مستقیم از خط تولید. بدون مزاحمت، لغو عضویت در هر زمان.

خوراک RSS در دسترس · بدون هرزنامه