انتشار یک نسخه جدید از برنامه‌ای که تصویر بزرگی دارد می‌تواند صدها گره را تقریباً همزمان به رجیستری بفرستد. هر گره ظاهراً کار ساده‌ای انجام می‌دهد، اما مجموع درخواست‌ها پهنای باند خروجی رجیستری یا مسیر میان مراکز داده را اشباع می‌کند. برخی Podها تا پایان دریافت لایه‌ها منتظر می‌مانند و زمان انتشار از کنترل خارج می‌شود. Dragonfly در این مقاله به پروژه توزیع فایل همتا‌به‌همتا اشاره دارد. این پروژه به گره‌هایی که قطعه‌ای را دریافت کرده‌اند امکان می‌دهد آن قطعه را در اختیار دیگران بگذارند. برای ارزیابی نتیجه باید مسیر اولین دانلود، دانلودهای بعدی و هزینه‌ای را که به شبکه محلی منتقل می‌شود جداگانه دید.
واحد کار فایل است و انتقال به قطعه‌ها تقسیم می‌شود
در مسیر توزیع، یک درخواست دانلود به صورت یک task شناخته می‌شود. فایل به قطعه‌هایی تقسیم می‌شود که می‌توانند از والدهای مناسب دریافت شوند. اطلاعات موجود بودن قطعه‌ها به زمان‌بندی کمک می‌کند تا یک گره برای دریافت تمام داده الزاماً به یک مبدأ وابسته نباشد. در مثال تصویر کانتینر، رفتار واقعی به درخواست‌های runtime و مسیر رجیستری وابسته است. یک تصویر شامل مانیفست و لایه‌هایی است که الگوی اندازه و استفاده مجدد متفاوتی دارند. کاهش بار برای لایه مشترک و بزرگ ممکن است چشمگیر باشد، در حالی که یک پاسخ کوچک یا کاملاً جدید الگوی دیگری دارد.
این تقسیم‌بندی اجازه می‌دهد دانلود و ارائه قطعه‌ها هم‌پوشانی داشته باشند. گره لازم نیست برای آغاز هر نوع مشارکت در شبکه منتظر تکمیل دانلود همه مشتریان بماند. اما استفاده از چند والد به معنی شتاب ثابت در هر شرایطی نیست. اگر همه والدها از یک مسیر محدود عبور کنند، افزایش تعداد ارتباط‌ها ظرفیت فیزیکی تازه نمی‌سازد. تأخیر شبکه، ظرفیت ارسال گره، سرعت ذخیره‌سازی و بار همزمان پردازش‌های دیگر تعیین می‌کنند چند منبع واقعاً سودمند است. آزمون باید هم سرعت کامل شدن فایل و هم مصرف منابع گره‌هایی را که به دیگران خدمت می‌دهند اندازه بگیرد.
Manager، Scheduler و Peer مسئولیت‌های متفاوت دارند
Manager اطلاعات تنظیمات و ارتباط میان بخش‌های سامانه را نگه می‌دارد و به مدیریت خوشه‌های توزیع کمک می‌کند. Scheduler برای یک دانلود والدهای مناسب را انتخاب می‌کند و درباره مسیر دریافت از منبع تصمیم می‌گیرد. Peer روی گره دریافت و ارسال داده را انجام می‌دهد. Seed Peer می‌تواند نقطه‌ای باشد که محتوا را از منبع اصلی دریافت می‌کند و به شبکه می‌رساند. این تفکیک روشن می‌کند که داده حجیم فایل لزوماً از خود Scheduler عبور نمی‌کند. یک خطای زمان‌بندی و یک خطای انتقال قطعه نشانه‌ها و حوزه مسئولیت متفاوتی دارند.
قرار دادن Seed Peer در شبکه باید با مسیر واقعی ترافیک هماهنگ باشد. اگر همه گره‌ها در شعبه‌ای دور از رجیستری قرار دارند، یک نقطه مناسب برای دریافت اولیه می‌تواند انتقال تکراری از لینک بین شعبه‌ها را کاهش دهد. اما همان نقطه به دیسک و ظرفیت ارسال کافی نیاز دارد. اگر ظرفیت آن فقط برای یک دانلود طراحی شده باشد، آغاز همزمان چند انتشار بزرگ می‌تواند آن را اشباع کند. افزونگی مؤلفه‌های مدیریت و زمان‌بندی نیز باید جدا از افزونگی مسیر داده طراحی شود. داشتن چند Peer، به تنهایی سلامت دسترسی به Scheduler یا مبدأ اصلی را اثبات نمی‌کند.
بار نخست چه اتفاقی می‌افتد؟
وقتی هنوز قطعه‌ای از فایل در شبکه مربوط در دسترس نیست، Peer درخواست را ثبت می‌کند و Scheduler بر اساس وضعیت task مسیر دریافت اولیه را انتخاب می‌کند. در الگوی مستند پروژه، Seed Peer می‌تواند از مبدأ بخواند و قطعه‌ها را برای سایر Peerها فراهم کند. این مرحله هنوز به دسترسی و سرعت منبع اصلی نیاز دارد. اگر رجیستری فایل را ارائه نکند یا اعتبار دسترسی رد شود، شبکه همتاها نمی‌تواند محتوایی را که هیچ عضو مجازی دریافت نکرده از نو بسازد. بنابراین تجربه اولین دانلود باید مستقل از تجربه دانلود پس از گرم شدن شبکه اندازه‌گیری شود.
در یک آزمایش مناسب، تصویر یا لایه‌ای انتخاب کنید که گره‌ها قبلاً نخوانده‌اند. زمان شروع درخواست، زمان دریافت نخستین قطعه و زمان تکمیل را ثبت کنید. سپس همان محتوا را در شرایط مشابه از مجموعه دیگری از گره‌ها بخواهید. اگر فقط زمان دوم گزارش شود، نتیجه تصویری خوش‌بینانه از انتشار واقعی نسخه‌های تازه می‌دهد. اگر فقط بار اول سنجیده شود، ارزش اشتراک قطعه بین گره‌ها دیده نمی‌شود. برای سرویس‌هایی با انتشار روزانه باید بدانید چه سهمی از لایه‌ها با نسخه قبلی مشترک است و چه سهمی در هر انتشار کاملاً تازه تولید می‌شود.
دانلودهای بعدی چگونه از شبکه محلی سود می‌برند؟
اگر Peer درخواست‌کننده همه قطعه‌های لازم را محلی داشته باشد، می‌تواند فایل را از داده موجود تحویل دهد. اگر بخشی از قطعه‌ها موجود باشد، زمان‌بندی می‌تواند والدهای دارای داده مناسب را معرفی کند و Peer از چند منبع قطعه دریافت کند. سود این روش به مدت ماندن قطعه‌ها و هم‌پوشانی تقاضا بستگی دارد. گره‌هایی که بلافاصله پس از دریافت حذف می‌شوند فرصت کوتاهی برای خدمت به دیگران دارند. پاک‌سازی بیش از حد تهاجمی نیز شبکه را مرتب به وضعیت سرد بازمی‌گرداند. در مقابل نگه‌داری طولانی همه فایل‌ها می‌تواند دیسک گره را با داده کم‌استفاده پر کند.
برای انتخاب ظرفیت cache، حجم تصاویر محبوب، فاصله بین انتشارها و عمر گره‌ها را کنار هم قرار دهید. به جای ثبت فقط تعداد hit، مقدار بایت صرفه‌جویی‌شده و زمان بازیابی را هم محاسبه کنید. هزار درخواست کوچک از cache شاید در شمارنده چشمگیر باشد ولی اثر کمتری از یک لایه بزرگ مشترک داشته باشد. همچنین کش محلی runtime کانتینر با قطعه‌های در اختیار Dragonfly یک لایه واحد نیست. ممکن است runtime قبلاً تصویر کامل را داشته باشد و اصلاً درخواست تازه‌ای نفرستد. اندازه‌گیری باید مشخص کند صرفه‌جویی از کدام لایه آمده تا طراحی ظرفیت بر داده درست استوار شود.
مسیر runtime، رجیستری و کنترل دسترسی
یکپارچه‌سازی با runtime باید درخواست‌های مورد نظر را به Peer هدایت کند و ارتباط با رجیستری را مطابق تنظیمات سازمان انجام دهد. نسخه runtime، شیوه mirror یا proxy و قواعد نام رجیستری روی مسیر اثر دارند. موفقیت یک دانلود مستقیم از خط فرمان اثبات نمی‌کند Kubernetes از همان مسیر استفاده کرده است. برای بررسی، روی یک گره آزمایشی تصویر تازه‌ای از همان رجیستری بگیرید و شواهد درخواست در runtime، Peer و مبدأ را با هم تطبیق دهید. اگر رجیستری خصوصی است، رفتار اعتبارنامه و محدوده دسترسی به مخزن خصوصی باید صریحاً آزموده شود.
اشتراک قطعه در شبکه نیازمند طراحی مرز اعتماد است. مدیر باید بداند کدام گره‌ها اجازه شرکت در توزیع دارند، ارتباط اجزا چگونه محافظت می‌شود و درخواست‌کننده با چه مجوزی محتوا را دریافت می‌کند. اعتبار محتوای تصویر نیز موضوع جداگانه‌ای است. دریافت موفق یک فایل یا تطابق digest محتوایی می‌تواند تغییر ناخواسته داده را آشکار کند، ولی برای تصمیم درباره اینکه ناشر مورد اعتماد بوده باید زنجیره انتشار و سیاست امضای سازمان بررسی شود. قرار دادن یک توزیع‌کننده در مسیر، مسئولیت بررسی منبع تصویر یا کنترل دسترسی به داده حساس را از سامانه اصلی حذف نمی‌کند.
جابه‌جایی بار و اثر روی گره برنامه
کاهش ترافیک رجیستری معمولاً با افزایش تبادل میان Peerها همراه است. این ترافیک در شبکه‌ای با ظرفیت آزاد سودمند است، اما در یک خوشه پرتراکم می‌تواند با درخواست‌های برنامه رقابت کند. هنگام انتشار، مصرف دیسک گره، سرعت ارسال و دریافت، تعداد ارتباط‌ها و تأخیر سرویس اصلی را کنار هم ببینید. اگر زمان pull بهتر شود ولی درخواست کاربران همان گره کندتر شود، نتیجه باید با سیاست عملیاتی بازبینی شود. محدودکردن همزمانی یا جدا کردن منابع خدمت‌رسانی ممکن است تعادل بهتری بسازد. گره‌ای که برای استنتاج مدل یا پایگاه داده حساس استفاده می‌شود شاید بودجه ارسال متفاوتی داشته باشد.
مرز شبکه میان منطقه‌ها نیز اهمیت دارد. انتخاب والد نزدیک از دید نام خوشه لزوماً ارزان‌ترین مسیر واقعی را تضمین نمی‌کند. لینک بین منطقه‌ها ممکن است ظرفیت کمتر یا هزینه بیشتری از شبکه داخلی داشته باشد. برای انتشار بزرگ، بایت خروجی رجیستری، بایت میان منطقه‌ای و بایت درون منطقه را جدا اندازه بگیرید. کاهش عدد اول در کنار رشد بی‌رویه عدد دوم می‌تواند هزینه را جابه‌جا کند. ساختار خوشه‌های P2P و موقعیت Seed Peer باید این تفاوت را بازتاب دهد. آزمایش از یک منطقه تنها، اثر توپولوژی استقرار چندمنطقه‌ای را نشان نمی‌دهد.
اختلال مبدأ و مسیر بازگشت به منبع
سامانه می‌تواند در بعضی شرایط برای دریافت مستقیم از منبع اقدام کند. این رفتار هنگام فقدان والد مناسب یا شکست زمان‌بندی به حفظ امکان دانلود کمک می‌کند، اما بازگشت همزمان شمار زیادی Peer به مبدأ می‌تواند همان رجیستری را زیر بار ناگهانی ببرد. پس نرخ مراجعه مستقیم، خطاهای والد و توان مبدأ باید جداگانه پایش شوند. توقف یک Seed Peer، قطع ارتباط با Scheduler و خطای مجوز رجیستری سه سناریوی متفاوت‌اند. آزمایش هر سه نشان می‌دهد کدام درخواست از cache محلی کامل می‌شود، کدام به مسیر جایگزین می‌رود و کدام باید خطای قابل فهم دریافت کند.
فرض کنید انتشار یک نسخه فقط روی گره‌های یک رک کند شده است. ابتدا مشخص کنید آن گره‌ها واقعاً از Peer استفاده می‌کنند. سپس والدهای انتخاب‌شده، نسبت قطعه‌های محلی و زمان انتظار Scheduler را بررسی کنید. اگر قطعه‌ها موجودند ولی انتقال کند است، مسیر شبکه و دیسک والد و فرزند را بسنجید. اگر همه درخواست‌ها به مبدأ می‌روند، وضعیت cache، ثبت task و دسترسی به والدها را بررسی کنید. اگر حتی دانلود مستقیم شکست می‌خورد، مجوز و دسترس‌پذیری رجیستری در اولویت قرار می‌گیرد. با این ترتیب خطای محلی گره به اشتباه به رجیستری یا scheduler نسبت داده نمی‌شود.
گزارش انتشار باید زمان آماده شدن آخرین گره را هم نشان دهد. میانگین خوب گاهی گروه کوچکی از گره‌ها را پنهان می‌کند که به دلیل مسیر بین منطقه‌ای یا دیسک کند عقب مانده‌اند. مقایسه انتشار سرد و گرم، مقدار داده خوانده‌شده از منبع و تأثیر روی ترافیک عادی برنامه، مبنای تصمیم درباره ادامه استفاده از Dragonfly است. این سه مشاهده کمک می‌کند تیم اندازه cache، محل Seed Peer و محدودیت انتقال را بر اساس هزینه واقعی شبکه خود تنظیم کند.
