Arkvory

रीड गेटवे ​

रीड गेटवे एक अतिरिक्त API प्रोसेस है जो केवल डाउनलोड परोसता है। यह मुख्य API (writer) के साथ उसी सर्वर पर चलता है, वही PostgreSQL डेटाबेस और वही स्टोरेज डायरेक्टरी इस्तेमाल करता है, और writer तथा अन्य गेटवे के साथ एक ही डाउनलोड बजट साझा करता है।

अनेक समानांतर डाउनलोड को कई प्रोसेस पर बाँटने के लिए गेटवे इस्तेमाल करें, जबकि कुल डाउनलोड दर उस एक सीमा के भीतर रहती है जो आप तय करते हैं। गेटवे डेटा की प्रति नहीं बनाता। वह उन फ़ाइलों को पढ़ता है जो writer ने प्रकाशित की हैं, इसलिए गेटवे कभी पीछे नहीं रहता। यह आपको सर्वर या डिस्क के नुकसान से भी नहीं बचाता। उसके लिए बैकअप और मिरर देखें।

यह कैसे काम करता है ​

  • इंस्टॉलेशन में एक writer और अधिकतम 15 रीड गेटवे होते हैं। मिलकर वे अधिकतम 16 स्लॉट होते हैं। writer हमेशा स्लॉट 0 इस्तेमाल करता है। हर गेटवे 1 से लेकर स्लॉट की संख्या घटा एक तक अपना स्लॉट इस्तेमाल करता है।
  • सभी प्रोसेस एक ही PostgreSQL डेटाबेस और एक ही स्टोरेज डायरेक्टरी इस्तेमाल करते हैं। गेटवे जाँचता है कि स्टोरेज मौजूद है और उसी डेटाबेस की है। यह उसे कभी नहीं बनाता।
  • आप सभी प्रोसेस के लिए एक कुल डाउनलोड दर तय करते हैं। हर प्रोसेस को बराबर की निश्चित हिस्सेदारी मिलती है: कुल को स्लॉट की संख्या से भाग देकर, नीचे की ओर पूर्णांकित।
  • प्रोसेस डेटाबेस में लीज़ (lease) के ज़रिए अपना स्लॉट रखता है। अगर वह लीज़ खो देता है, तो नया payload परोसना बंद कर देता है और उसे रीस्टार्ट करना पड़ता है। इससे सभी हिस्सेदारियों का योग कुल के भीतर रहता है।

writer अपना सामान्य काम करता रहता है। यह अपलोड, कंसोल, पृष्ठभूमि क्लीनअप और सभी बदलाव लेता है। गेटवे कभी क्लीनअप नहीं चलाता।

गेटवे क्या अस्वीकार करता है ​

गेटवे केवल GET और HEAD स्वीकार करता है। जो भी अनुरोध कुछ बदलता है उसे HTTP 405 मिलता है, हेडर Allow: GET, HEAD और कोड read_only के साथ, भले ही कुंजी के पास लिखने के अधिकार हों। इसमें साइन-इन और स्वयं-पंजीकरण भी शामिल हैं। कंसोल केवल writer का हिस्सा है, इसलिए वह गेटवे पर उपलब्ध नहीं है।

हर पढ़त पर रिपॉज़िटरी अनुमतियाँ जाँची जाती हैं, जैसे writer पर। सत्र, व्यक्तिगत टोकन और सेवा कुंजियाँ गेटवे पर पढ़ने के लिए काम करती हैं।

आवश्यकताएँ ​

  • वही सर्वर। गेटवे को ठीक वही फ़ाइलें दिखनी चाहिए जो writer ने प्रकाशित की हैं, बिना किसी देरी के। rsync या किसी और अतुल्यकालिक कॉपी वाली स्वतंत्र डिस्क उपयुक्त नहीं हैं। अभी कोई नेटवर्क फ़ाइल सिस्टम प्रमाणित नहीं है, इसलिए गेटवे एक ही सर्वर पर कई प्रोसेस के लिए इस्तेमाल करें।
  • वही सेवा कुंजियाँ। हर प्रोसेस को वही ARKVORY_KEYS_FILE सामग्री दें, ताकि फ़ाइल कुंजियाँ और उनकी ID मेल खाएँ। प्रबंधित सेवा कुंजियाँ डेटाबेस में रहती हैं, इसलिए वे अपने-आप मेल खाती हैं।
  • अपना पोर्ट। एक ही होस्ट पर हर प्रोसेस को अपना ARKVORY_PORT चाहिए।
  • फ़ाइलों का केवल-पढ़ने योग्य दृश्य। जहाँ संभव हो, गेटवे के लिए स्टोरेज डायरेक्टरी को केवल-पढ़ने योग्य माउंट करें। HTTP इंकार ऑपरेटिंग सिस्टम के अधिकारों की जगह नहीं लेता। ध्यान दें कि गेटवे अब भी डेटाबेस में लिखता है: लीज़, स्टोरेज डायग्नोस्टिक्स, व्यक्तिगत टोकन का अंतिम-उपयोग समय और पढ़ी जा रही फ़ाइलों की रक्षा करने वाले लॉक।
  • डेटाबेस कनेक्शन। हर गेटवे को ARKVORY_DATABASE_POOL_SIZE से तीन अधिक कनेक्शन चाहिए। इन्हें PostgreSQL के max_connections में गिनें।

गेटवे चलाएँ ​

इंस्टॉलर API, वर्कर और बैकअप एजेंट को रजिस्टर करते हैं। वे गेटवे रजिस्टर नहीं करते, और arkvory status उसे प्रबंधित नहीं करता। आप गेटवे खुद शुरू करते हैं, इंस्टॉल किए गए रिलीज़ के API प्रोग्राम की एक और इंस्टेंस के रूप में, अपने एनवायरनमेंट और अपने सेवा प्रबंधक के अंतर्गत।

वे सेटिंग्स जो सभी प्रोसेस के लिए समान हैं, कुल दो प्रोसेस के लिए, कुल मिलाकर 64 MiB/s और एक खाते या कुंजी के लिए 16 MiB/s:

dotenv
ARKVORY_GATEWAY_SLOTS=2
ARKVORY_SHARED_DOWNLOAD_BYTES_PER_SECOND=67108864
ARKVORY_SHARED_DOWNLOAD_BYTES_PER_SECOND_PER_PRINCIPAL=16777216

writer यह जोड़ता है:

dotenv
ARKVORY_ROLE=api
ARKVORY_GATEWAY_SLOT=0

गेटवे यह जोड़ता है:

dotenv
ARKVORY_ROLE=reader
ARKVORY_GATEWAY_SLOT=1
ARKVORY_PORT=8081

गेटवे को बाकी API सेटिंग्स भी चाहिए: उसी डेटाबेस का ARKVORY_DATABASE_URL, उसी स्टोरेज की ओर ले जाने वाला ARKVORY_DATA_DIR (पथ अलग हो सकता है, स्टोरेज की पहचान मेल खानी चाहिए), ARKVORY_KEYS_FILE, और HTTPS सेटिंग्स अगर गेटवे अन्य कंप्यूटरों से पहुँच योग्य है। एनवायरनमेंट वेरिएबल देखें।

वेरिएबलनियम
ARKVORY_GATEWAY_SLOTSwriter सहित प्रोसेस की संख्या, 2–16
ARKVORY_GATEWAY_SLOTइस प्रोसेस का स्लॉट, 0 से स्लॉट की संख्या घटा एक तक। writer 0 है, गेटवे 0 नहीं है
ARKVORY_SHARED_DOWNLOAD_BYTES_PER_SECONDआवश्यक। सभी प्रोसेस की कुल दर, कम से कम स्लॉट की संख्या का 65 536 गुना, अधिकतम 1 TiB प्रति सेकंड
ARKVORY_SHARED_DOWNLOAD_BYTES_PER_SECOND_PER_PRINCIPALसभी प्रोसेस में एक खाते या कुंजी के लिए कुल दर। 0 का मतलब कोई सीमा नहीं। वरना ऊपर जैसी ही श्रेणी

अगर आप इनमें से कोई भी वेरिएबल सेट करते हैं, तो हर प्रोसेस पर स्लॉट, स्लॉट की संख्या और कुल दर सेट करें। अमान्य मान प्रोसेस को शुरू होते समय रोक देता है, उस वेरिएबल का नाम बताने वाले संदेश के साथ। साझा डाउनलोड कॉन्फ़िगरेशन के बिना गेटवे शुरू होने से इंकार कर देता है।

  1. स्लॉट की संख्या और दरें तय करें।
  2. writer में तीन साझा वेरिएबल और writer के अपने दो वेरिएबल जोड़ें, और writer को रीस्टार्ट करें। यह नीति डेटाबेस में सहेजता है।
  3. गेटवे को उसके अपने वेरिएबल के साथ शुरू करें। अगर उसके मान सहेजी गई नीति से अलग हैं, तो वह शुरू नहीं होता।
  4. हर प्रोसेस की तैयारी जाँचें, और हर एक पर रेंज डाउनलोड का परीक्षण करें। गेटवे की निगरानी देखें।
  5. तभी गेटवे को अपने लोड बैलेंसर में जोड़ें।

कुछ नियम प्रोफ़ाइल की रक्षा करते हैं:

  • गेटवे तभी शुरू हो सकता है जब writer नीति सहेज चुका हो।
  • डेटाबेस में नीति मौजूद होने के बाद, इन वेरिएबल के बिना writer शुरू नहीं होता। यह इस संदेश के साथ रुक जाता है कि डेटाबेस को साझा डाउनलोड कॉन्फ़िगरेशन चाहिए।
  • चालू इंस्टॉलेशन पर आप दरें या स्लॉट की संख्या नहीं बदल सकते। कॉन्फ़िगरेशन बदलें देखें।

डाउनलोड बजट ​

हर प्रोसेस को total / slots मिलता है, नीचे की ओर पूर्णांकित। यही एक खाते या कुंजी की दर पर भी लागू होता है। उदाहरण के लिए, 64 MiB/s और 2 स्लॉट के साथ, हर प्रोसेस अधिकतम 32 MiB/s परोसता है, और एक खाते को हर प्रोसेस में अधिकतम 8 MiB/s मिलता है।

  • एक प्रोसेस दूसरे की हिस्सेदारी इस्तेमाल नहीं कर सकता। अगर दो में से एक प्रोसेस रुक जाए, तो आपको कुल का आधा मिलता है। इससे सीमा सरल और जाँचने योग्य रहती है।
  • स्थानीय सेटिंग्स ARKVORY_DOWNLOAD_BYTES_PER_SECOND और ARKVORY_DOWNLOAD_BYTES_PER_SECOND_PER_PRINCIPAL हिस्सेदारी घटा सकती हैं, बढ़ा नहीं।
  • अपलोड बजट writer पर ही रहते हैं, क्योंकि गेटवे कोई अपलोड नहीं लेते।
  • प्रतीक्षारत ट्रांसफ़र की कतार और सक्रिय ट्रांसफ़र की सीमा हर प्रोसेस पर स्थानीय रहती है, इसलिए सभी प्रोसेस की क्षमताएँ जुड़ जाती हैं।

यह सीमा एप्लिकेशन के payload पर लागू होती है, थोड़े burst के साथ। यह नेटवर्क इंटरफ़ेस की सीमा नहीं है। एनवायरनमेंट वेरिएबल देखें।

लीज़ और विफलताएँ ​

डेटाबेस एक स्लॉट को 10 सेकंड के लिए आरक्षित करता है। प्रोसेस हर 2 सेकंड में इसे नवीनीकृत करता है, और वह लीज़ पर स्थानीय रूप से अधिकतम 8 सेकंड तक भरोसा करता है। जिस लीज़ का समय बीत चुका है वह कभी फिर जीवित नहीं होती, भले ही देर से उत्तर आ जाए।

  • लीज़ खो गई। प्रोसेस नया payload देना बंद कर देता है, नए अधिकृत अनुरोधों का उत्तर 503 से देता है और उसे रीस्टार्ट चाहिए। जो डाउनलोड कट गया था वह रीट्राई या रेंज अनुरोध से जारी रह सकता है। यह writer पर भी लागू होता है।
  • उसी स्लॉट का रीस्टार्ट। नया प्रोसेस प्रतीक्षा करता है जब तक पुराना आरक्षण समाप्त न हो जाए, उसके अंतिम नवीनीकरण के बाद अधिकतम 10 सेकंड, और कुल मिलाकर अधिकतम 15 सेकंड। अगर कोई चालू गेटवे अब भी स्लॉट रखे हुए है, तो नया प्रोसेस busy के साथ रुक जाता है।
  • घड़ियाँ। लीज़ स्थिर घड़ियों पर निर्भर करती हैं। डेटाबेस सर्वर की घड़ी में उछाल, या रुकी हुई वर्चुअल मशीन, किसी प्रोसेस को उसकी लीज़ से आगे परोसते रहने दे सकती है। ऐसी स्थिति में रिप्लेसमेंट शुरू करने से पहले पुराने प्रोसेस रोक दें।
  • डेटाबेस विफलता। डेटाबेस कमज़ोर कड़ी है। अगर वह पहुँच से बाहर हो जाए, तो लीज़ समाप्त हो जाती हैं और सभी प्रोसेस payload परोसना बंद कर देते हैं।

जिस मृत प्रोसेस ने अपना नेटवर्क खो दिया है, सर्वर उसे केवल TCP keepalive के ज़रिए भाँप सकता है। PostgreSQL पर tcp_keepalives_idle, tcp_keepalives_interval और tcp_keepalives_count सेट करें, उदाहरण के लिए 10, 5 और 3 सेकंड, या tcp_user_timeout सेट करें। इनके बिना, नया writer या वर्कर ऑपरेटिंग सिस्टम के लंबे डिफ़ॉल्ट टाइमआउट तक प्रतीक्षा कर सकता है।

गेटवे की निगरानी ​

  • GET /health/status सार्वजनिक है और केवल ready, unavailable या draining लौटाता है, 503 के साथ जब प्रोसेस परोस नहीं सकता (स्लॉट या लीज़ खोई, draining)। इसे अपने लोड बैलेंसर के लिए इस्तेमाल करें।
  • GET /health/ready के लिए कुंजी चाहिए। यह role, writable (गेटवे पर हमेशा false), slot, slots, active और leaseSeconds वाला sharedDownloads, और स्थानीय ट्रांसफ़र कतारों की संख्याएँ लौटाता है। स्लॉट खोने पर यह 503 उत्तर देता है। स्टैंडअलोन इंस्टॉलेशन के लिए, sharedDownloads null है।
  • GET /health/live केवल यह दिखाता है कि HTTP प्रोसेस चल रहा है। यह नहीं बताता कि गेटवे परोस सकता है या नहीं।
  • हर प्रोसेस का GET /health/metrics केवल उसी प्रोसेस को दिखाता है। हर गेटवे को scrape करें और प्रोसेस-स्तर के HTTP और ट्रांसफ़र मेट्रिक्स इस्तेमाल करें।

हर प्रोसेस को अलग-अलग जाँचें। writable false वाला गेटवे सामान्य है। निगरानी देखें।

अनुरोध रूट करें ​

लोड बैलेंसर आपका है। Arkvory कोई बैलेंसर नहीं देता।

  • डेटा बदलने वाला हर अनुरोध, और /console/, writer को भेजें।
  • आप बाइट पढ़त को writer और गेटवे के बीच बाँट सकते हैं: /api/v1/repositories/NAME/artifacts/ID/content, .../packages/content और .../asset/content के लिए GET और HEAD। बाकी अनुरोध writer पर ही रखें।
  • Authorization, Range, If-Range और ETag हेडर पास करें। पूरी फ़ाइल को बफ़र किए बिना body स्ट्रीम करें। क्लाइंट को ऐसे URL पर रीडायरेक्ट न करें जिसमें कुंजी हो।
  • बैलेंसर में बैकएंड तभी जोड़ें जब उसकी प्रमाणित तैयारी ठीक हो।

TypeScript SDK एक ही पते के पीछे किसी दूसरे स्वस्थ बैकएंड के ज़रिए बाधित डाउनलोड जारी रख सकता है। चल रहा TCP कनेक्शन सर्वरों के बीच नहीं जाता।

कॉन्फ़िगरेशन बदलें ​

इंस्टॉलेशन चालू रहते हुए आप दरें या स्लॉट की संख्या नहीं बदल सकते, और नीति मौजूद रहते हुए आप एक प्रोसेस पर वापस नहीं जा सकते। भले ही सभी गेटवे रुके हों, सहेजी गई नीति बिना सीमा के शुरू होने से रोकती है।

  1. आने वाला ट्रैफ़िक रोकें। writer, हर गेटवे और वर्कर रोकें, और पुष्टि करें कि वे वाकई रुक गए हैं।
  2. प्रतीक्षा करें जब तक डेटाबेस की लीज़ समाप्त न हो जाएँ।
  3. बैकअप बनाएँ। बैकअप देखें।
  4. Arkvory डेटाबेस का व्यवस्थापक एक ही ट्रांज़ैक्शन में arkvory_gateway_leases और arkvory_download_policy तालिकाओं की सभी पंक्तियाँ हटा देता है। यह केवल समन्वय स्थिति रीसेट करता है, कैटलॉग नहीं।
  5. writer को नई सेटिंग्स के साथ शुरू करें, फिर गेटवे।

यह कभी न करें जबकि कोई प्रोसेस अब भी चल सकता हो।

अपडेट को भी उतनी ही सावधानी चाहिए। इंस्टॉलेशन अपडेट होने से पहले हर गेटवे रोकें, और बाद में उन्हें नए रिलीज़ से शुरू करें। नए डेटाबेस स्कीमा के सामने पुराना कोड चलाता रहने वाला गेटवे खुद को तैयार नहीं बताता। क्लीनअप के ऑफ़लाइन मरम्मत उपकरणों के लिए भी सभी गेटवे रोकना ज़रूरी है। writer का ऑनलाइन क्लीनअप ऐसा नहीं माँगता।

गेटवे या मिरर ​

रीड गेटवेमिरर
यह क्या हैएक ही सर्वर और स्टोरेज पर अधिक API प्रोसेसडेटा की प्रति वाला दूसरा, स्वतंत्र इंस्टॉलेशन
डेटाएक प्रति, लाइव पढ़ी जाती हैदूसरी प्रति, देरी से खींची जाती है
खाते और कुंजियाँwriter जैसे हीअपने
अतिरिक्त डिस्ककोई नहींहाँ, जितनी रिपॉज़िटरी को चाहिए
चाहिएवही डेटाबेस और वही फ़ाइल सिस्टमस्रोत तक HTTPS लिंक और केवल-पढ़ने योग्य कुंजी
खोए सर्वर या डिस्क से बचाता हैनहींआंशिक रूप से: स्रोत बंद रहते हुए यह परोसता है, और आप उस पर स्विच कर सकते हैं
इसके लिए इस्तेमाल करेंएक साझा दर सीमा के साथ अधिक समानांतर डाउनलोडदूसरी साइट, उपयोगकर्ताओं के करीब कार्यालय, स्टैंडबाय

दोनों बैकअप के अतिरिक्त हैं, उनके विकल्प नहीं।

सीमाएँ ​

  • सभी प्रोसेस को एक सर्वर और एक स्टोरेज डायरेक्टरी साझा करनी चाहिए। अलग मशीनों के लिए ऐसा फ़ाइल सिस्टम चाहिए जिसका इसके लिए परीक्षण हुआ हो, और अभी किसी का परीक्षण नहीं हुआ।
  • कोई इंस्टॉलर समर्थन नहीं, कोई स्वचालित फ़ेलओवर नहीं और कोई अंतर्निहित बैलेंसर नहीं।
  • एक डेटाबेस और एक writer अकेली विफलता-बिंदु बने रहते हैं।
  • बजट प्रति स्लॉट निश्चित है और दोबारा वितरित नहीं होता, और कोई प्राथमिकता शेड्यूलिंग नहीं है।
  • चालू इंस्टॉलेशन पर आप नीति नहीं बदल सकते।

Arkvory · ProAnimaStudio