
ستون حاوية على خادم واحد
صندوق معادن عارية واحد يشغل عشرات إلى مئات حاويات Hoody. يجعل KSM و BTRFS dedup التكلفة الإضافية قريبة من الصفر.
نسخة احتياطيّة لـ Postgres بحجم 200 جيجابايت في فرانكفورت. صندوق جديد في سنغافورة. تتجاوز رحلة S3. أمر curl واحد يُمرِّر pg_dump إلى رابط Hoody Pipe؛ أمر curl على الجانب الآخر يبثّه مباشرةً إلى psql. البايتات في الطيران، لا في الراحة.
200 جيجابايت · صفر قفزات · صفر احتفاظ
Hoody Pipe مسارٌ مُسمّى على خادم HTTP. المرسِل يُرسل بثّاً إليه بـ PUT، المستقبِل يطلب نفس المسار بـ GET، والخادم يصل الاثنين. لا شيء يُكتب على القرص؛ الأنبوب يحتفظ بصفر بايت بحكم التصميم.
من صندوق المصدر، pg_dump | gzip | curl -T - إلى رابط الأنبوب. جسم PUT يُبثّ بأقصى ما يسمح به الضغط العكسي لـ TCP. الخادم يحتفظ بالاتّصال حتى يظهر مستقبِل على نفس المسار.
PUT /api/v1/pipe/migrationحين يصل GET المستقبِل إلى نفس المسار، Hoody يصل بايتات الرفع مباشرةً إلى استجابة التنزيل. لا ذاكرة وسيطة، لا قرص مرحلي، لا التزام غير متزامن — فقط بثّ مباشر بين مقبسَي HTTP.
0 بايت على القرصمن صندوق الوجهة، curl يطلب المسار ويُمرِّر الاستجابة عبر gunzip | psql. بثّ جانب المستقبل ينتهي لحظة وصول آخر بايت من المرسِل. لا إعادة محاولة، لا بيان، لا تنظيف.
GET /api/v1/pipe/migrationترتيب الاتّصال غير مهمّ — يستطيع المستقبِل أن يُرسل curl أوّلاً وينتظر حتى يتّصل المرسِل (أو العكس)، حتى TTL الأنبوب البالغ 5 دقائق. الضغط العكسي يتدفّق من طرف لطرف: psql بطيء يخنق curl على المصدر. لا طابور يمكن أن يفيض لأنّه لا يوجد طابور.
هذه ليست شيفرة وهميّة. افتح طرفيتين على الخادمَين، شغّل أمراً واحداً على كلٍّ، وشاهد نسخة احتياطيّة 200 جيجابايت تغادر سحابة وتصل إلى أخرى.
PUT (curl -T) مُفضَّل لأنّه الطريقة التي يريد بها curl رفع بثّ. POST يعمل بنفس الطريقة — نفس المسار، نفس رسائل الحالة. استخدم ?n=N على الجانبَين إن أردت تفرّع نفس النسخة إلى مستقبِلين كثر.
حاسوب محمول ثالث يفتح نفس رابط الأنبوب مع ?progress فيحصل على تغذية SSE فوريّة بالبايتات في الثانية والزمن المتبقّي والمستقبِلين المتّصلين. المشاهدة لا تستهلك خانة مستقبِل — خمسون زميلاً يستطيعون مشاهدة الهجرة دون تغيير قيمة n أو التدخّل في النقل.
رحلة S3 تبدو بسيطة على لوحة بيضاء. في الإنتاج إنّها كومة من القطع المتحرّكة، كلّها تتقاضى بالثانية. الأنبوب يطوي الكومة كلّها داخل النقل ذاته.
S3، GCS، Azure Blob — رحلة الذهاب والإياب موجودة فقط لأنّه لم يكن هناك مكان آخر لتركن البايتات. الأنبوب هو المسار. لا دلو يجب توفيره، لا قاعدة دورة حياة، لا تنظيف لاحق.
خروج عند الرفع، خروج عند التنزيل — مرّتان. مع الأنبوب، البايتات تغادر فرانكفورت وتصل سنغافورة في قفزة واحدة. أنت تدفع للثواني التي كان فيها الاتّصال مفتوحاً، لا لتخزين ستحذفه غداً.
مراقبتك تفهم HTTP أصلاً. وكذلك VPN، وجدارك الناري، وسجلّ التدقيق. لا هويّة IAM جديدة، لا SDK جديد، لا وضع فشل جديد — إنّه أمر curl.
السرعة محدودة بأبطأ رابط من طرف لطرف (خروج فرانكفورت، دخول سنغافورة، نافذة TCP لديك). أنبوب Hoody يحتفظ بصفر بايت — لا تخزين على الخادم؛ الضغط العكسي يتدفّق مباشرةً بين الطرفين.
طرفيّتان، رابط واحد، لا طبقة تخزين ثالثة.
كل الهجرة لها نفس شكل cat file | wc -l. كون الأنبوبَين يقعان في مراكز بيانات مختلفة هو تفصيل تنفيذ للرابط.
أيّ شيء وُجد فقط لأنّه لم يكن لدى أحد مسار HTTP يبثّ. الأنبوب يطوي حزمة هجرة البيانات بأكملها في أمر curl واحد على كل جانب.
تجاوز الدلو. النقل هو الرابط.