उच्च उपलब्धता क्लस्टर

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

क्लस्टर एक साइट के भीतर सर्वर, डिस्क या नेटवर्क लिंक के खो जाने से बचाता है। यह पूरी साइट के खो जाने से नहीं बचाता। इसके लिए किसी दूसरी साइट पर मिरर और क्लस्टर के बाहर बैकअप रखें।

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

• एक वॉल्यूम, सिंक्रोनस कॉपी। DRBD 9 वॉल्यूम की हर राइट को पूरा होने से पहले दूसरे सर्वर पर कॉपी करता है (प्रोटोकॉल C)। पूरा इंस्टॉलेशन वॉल्यूम पर रहता है: डेटाबेस, स्टोरेज, कॉन्फ़िगरेशन और रिलीज़। कैटलॉग और फ़ाइल बाइट कभी अलग नहीं होते।
• Pacemaker तय करता है कि Arkvory कहाँ चलेगा। Corosync और Pacemaker कोरम बनाए रखते हैं, सक्रिय सर्वर चुनते हैं और क्रम से शुरू करते हैं: वॉल्यूम, फ़ाइल सिस्टम, वॉल्यूम पर रखे रूप में सेवाएँ (arkvory-units), डेटाबेस, arkvory-replica, API, वर्कर, बैकअप एजेंट, अपडेट टाइमर और एक वर्चुअल IP पता। Arkvory का अपना कोई चुनाव नहीं होता।
• फ़ेंसिंग अनिवार्य है। दूसरे सर्वर के कार्यभार संभालने से पहले Pacemaker विफल सर्वर को पावर डिवाइस (IPMI, iDRAC, iLO, Redfish, PDU) या हाइपरवाइज़र के ज़रिए बंद कर देता है। फ़ेंसिंग के बिना दो सर्वर एक साथ राइट कर सकते हैं। फ़ेंसिंग के बिना क्लस्टर शुरू नहीं होता।
• हर स्वीकृत राइट के लिए दो कॉपी। Arkvory किसी राइट का उत्तर सफलता से तभी देता है जब राइट कम से कम दो पूरी कॉपी पर हो (राइट और कॉपी देखें)। कोई कॉपी कम हो तो राइट रुक जाती हैं और रीड जारी रहती हैं।

प्रोफ़ाइल	डेटा सर्वर	विटनेस	जब एक डेटा सर्वर विफल हो
ha-2	2	अनिवार्य: बिना डेटा वाला एक छोटा सर्वर जो corosync-qnetd और DRBD टाईब्रेकर चलाता है	सर्वर लौटने या ऑपरेटर के निर्णय तक राइट रुकी रहती हैं
ha-3	3	उपयोग नहीं होता: तीनों सर्वर बहुमत से तय करते हैं	राइट जारी रहती हैं: दो कॉपी बची रहती हैं

ha-3 अनुशंसित प्रोफ़ाइल है। ha-2 कम खर्चीला है और डेटा को एक ही कॉपी में रखने के बजाय ईमानदारी से राइट रोक देता है।

क्लस्टर नेटिव Linux पैकेज के लिए है। Windows इंस्टॉलेशन और Docker Compose मिरर और बैकअप के साथ स्टैंडअलोन सर्वर ही रहते हैं।

राइट और कॉपी

पूरी कॉपी का मतलब है सक्रिय सर्वर की लोकल डिस्क, जब वह अप-टू-डेट हो, साथ में हर वह दूसरा डेटा सर्वर जो जुड़ा हो, रेप्लिकेट कर रहा हो और अप-टू-डेट हो। जो सर्वर री-सिंक्रोनाइज़ हो रहा है, वह अप-टू-डेट होने तक नहीं गिना जाता। विटनेस के पास डेटा नहीं होता और वह कभी नहीं गिना जाता।

डेटा बदलने वाले हर अनुरोध (HTTP API, कंटेनर रजिस्ट्री, Git LFS, npm) की दो बार जाँच होती है:

• चलने से पहले, पिछले एक सेकंड की कॉपी के आधार पर;
• डेटा कमिट और सिंक हो जाने के बाद, वॉल्यूम की ताज़ा रीडिंग के आधार पर।

जब राइट के लिए ज़रूरी संख्या से कम पूरी कॉपी हों, तो क्लाइंट को कोड unavailable, कारण replication_degraded और Retry-After हेडर के साथ HTTP 503 मिलता है, कभी 2xx नहीं। अपलोड पूरा करने वाले जॉब की स्थिति (GET /api/v1/jobs/{id}) की जाँच भी इसी तरह होती है, क्योंकि वह क्लाइंट को बताती है कि बड़ा अपलोड प्रकाशित हो गया है।

कमिट के बाद का 503 बताता है कि ऑपरेशन शायद केवल एक कॉपी में मौजूद है। वही Idempotency-Key लेकर अनुरोध दोहराएँ: दोहराव मौजूदा परिणाम लौटाता है, और जब दो कॉपी फिर मौजूद हो जाती हैं, तो उसका 2xx इसकी पुष्टि करता है।

राइट रुकी होने पर भी रीड, डाउनलोड, कंसोल, साइन-इन और साइन-आउट, फ़ीडबैक और Git LFS का बैच अनुरोध काम करते हैं।

कंसोल में साइन-इन किया हुआ व्यवस्थापक, जब तक राइट रुकी हैं या एकल-कॉपी निर्णय सक्रिय है, एक बैनर देखता है।

आवश्यकताएँ

• दो या तीन डेटा सर्वर, जिन पर वही Linux डिस्ट्रीब्यूशन और Arkvory पैकेज का वही संस्करण हो, और प्रत्येक पर वॉल्यूम के पूरे आकार की एक डिस्क (या लॉजिकल वॉल्यूम)। पूरे स्टोरेज और डेटाबेस के हिसाब से योजना बनाएँ।
• ha-2 के लिए विटनेस के रूप में तीसरा छोटा सर्वर। उसे डेटा के लिए डिस्क नहीं चाहिए और वह Arkvory नहीं चलाता।
• सर्वरों के बीच कम लेटेंसी वाला नेटवर्क। हर राइट दूसरे सर्वरों का इंतज़ार करती है, इसलिए लेटेंसी हर राइट में जुड़ जाती है। हो सके तो समर्पित लिंक इस्तेमाल करें।
• DRBD 9 (कर्नेल मॉड्यूल और drbd-utils 9; कई डिस्ट्रीब्यूशन पुराना 8.4 मॉड्यूल देते हैं, इसलिए LINBIT के पैकेज इस्तेमाल करें), pacemaker, pcs, corosync, resource-agents (Ubuntu पर resource-agents-base और resource-agents-extra), आपके हार्डवेयर के लिए फ़ेंस एजेंट। ha-2 के लिए: डेटा सर्वरों पर corosync-qdevice और विटनेस पर corosync-qnetd।
• हर डेटा सर्वर के लिए एक फ़ेंस डिवाइस और उसके क्रेडेंशियल।
• सर्वरों के नेटवर्क में एक खाली IP पता। क्लाइंट इसी वर्चुअल पते से जुड़ते हैं।
• वर्चुअल पते के लिए TLS सर्टिफ़िकेट। सर्टिफ़िकेट और कुंजी वॉल्यूम पर रखें, ताकि हर सर्वर उन्हें उसी पथ पर पाए।

क्लस्टर बनाएँ

नीचे के कमांड डिफ़ॉल्ट रिसोर्स नाम arkvory, इंस्टॉलेशन डायरेक्टरी /opt/proanima-arkvory और बैकिंग डिस्क के रूप में /dev/vg0/arkvory इस्तेमाल करते हैं। इन्हें root के रूप में चलाएँ।

1. हर डेटा सर्वर पर Arkvory पैकेज को इंस्टॉल किए बिना अनपैक करें। इससे फ़ाइलें और arkvory कमांड जुड़ जाते हैं और /opt/proanima-arkvory में कुछ नहीं बनता:

   dpkg --unpack Arkvory-amd64.deb

   RPM पैकेज के साथ, उसकी स्क्रिप्ट चलाए बिना फ़ाइलें इंस्टॉल करें: rpm -i --noscripts Arkvory-x86_64.rpm। पहले सर्वर पर आप इसके बजाय चरण 5 में पैकेज सामान्य रूप से इंस्टॉल करते हैं, इसलिए चरण 2 की योजना किसी दूसरे डेटा सर्वर पर बनाएँ।

2. एक डेटा सर्वर पर योजना बनाएँ। यह DRBD रिसोर्स और Pacemaker कमांड एक डायरेक्टरी में लिखती है, ताकि आप उन्हें जाँच सकें:

   arkvory cluster-plan --cluster ha-2 \
     --nodes node-a=10.0.0.11,node-b=10.0.0.12 --witness witness=10.0.0.13 \
     --disk /dev/vg0/arkvory --fence-agent fence_ipmilan \
     --virtual-ip 10.0.0.100/24 --output /root/arkvory-plan

   ha-3 के लिए --nodes में तीन सर्वर दें और --witness छोड़ दें। वैकल्पिक: --cluster-resource, --drbd-minor (डिफ़ॉल्ट 0), --drbd-port (डिफ़ॉल्ट 7789), --filesystem (xfs या ext4, डिफ़ॉल्ट xfs)। नाम सर्वरों के होस्ट नाम होने चाहिए। पते IPv4 होते हैं।

3. विटनेस समेत हर सर्वर पर arkvory.res को /etc/drbd.d/ में कॉपी करें। डेटा सर्वरों पर मेटाडेटा बनाएँ और हर जगह रिसोर्स चालू करें:

   drbdadm create-md arkvory   # data servers only
   drbdadm up arkvory          # every server

   विटनेस पर systemctl enable drbd@arkvory.service भी चलाएँ, ताकि टाईब्रेकर रीस्टार्ट के बाद लौट आए।

   योजना लौटती हुई कॉपी को राइट लोड के दौरान भी कम से कम 20 MB/s पर और अधिकतम 1 GB/s पर री-सिंक्रोनाइज़ होने देती है। disk सेक्शन में c-min-rate और c-max-rate को उस मान पर रखें जो आपका रेप्लिकेशन लिंक संभाल सके।

4. पहले डेटा सर्वर पर उसे प्राइमरी बनाएँ, फ़ाइल सिस्टम बनाएँ और उसे माउंट करें। नई खाली डिस्क के साथ पहले प्रारंभिक सिंक्रोनाइज़ेशन छोड़ दें:

   drbdadm new-current-uuid --clear-bitmap arkvory/0
   drbdadm primary arkvory
   mkfs.xfs /dev/drbd0
   mkdir -p /opt/proanima-arkvory && mount /dev/drbd0 /opt/proanima-arkvory

5. माउंट किए गए वॉल्यूम में Arkvory इंस्टॉल करें (RPM के साथ dpkg --configure के बजाय rpm -i Arkvory-x86_64.rpm), TLS फ़ाइलें वॉल्यूम पर रखें और क्लस्टर मोड चालू करें:

   dpkg --configure proanima-arkvory
   install -d -m 0750 -o root -g arkvory /opt/proanima-arkvory/config/tls
   install -m 0644 tls.crt /opt/proanima-arkvory/config/tls/tls.crt
   install -m 0640 -g arkvory tls.key /opt/proanima-arkvory/config/tls/tls.key
   arkvory configure --root /opt/proanima-arkvory --tls-cert /opt/proanima-arkvory/config/tls/tls.crt --tls-key /opt/proanima-arkvory/config/tls/tls.key --listen-host 0.0.0.0
   arkvory configure --root /opt/proanima-arkvory --cluster ha-2

   configure --cluster जाँचता है कि इंस्टॉलेशन डायरेक्टरी माउंट किया हुआ DRBD डिवाइस है, यह सर्वर प्राइमरी है और कम से कम दो कॉपी पूरी हैं। यह arkvory-replica शुरू करता है, Arkvory को केवल दो पूरी कॉपी होने पर राइट स्वीकार करने वाला बनाता है और Arkvory सेवाओं का स्वचालित शुरू होना बंद कर देता है: अब से उन्हें Pacemaker शुरू करता है। कोई चरण विफल हो तो स्टैंडअलोन कॉन्फ़िगरेशन वापस बहाल हो जाता है।

6. पहले सर्वर पर Arkvory रोकें और वॉल्यूम छोड़ दें:

   arkvory cluster-release --root /opt/proanima-arkvory

   कमांड Arkvory सेवाओं को क्रम से रोकता है, वॉल्यूम अनमाउंट करता है और इस सर्वर को सेकेंडरी बनाता है।

7. बाकी हर डेटा सर्वर पर बारी-बारी से सर्वर तैयार करें:

   arkvory cluster-node --root /opt/proanima-arkvory
   dpkg --configure proanima-arkvory   # केवल .deb; RPM के साथ और कुछ नहीं चाहिए

   cluster-node वॉल्यूम लेता है, सर्वर तैयार करता है और वॉल्यूम फिर छोड़ देता है, किसी चरण के विफल होने पर भी; रिपोर्ट पहली त्रुटि की होती है। --cluster-resource केवल तब चाहिए जब रिसोर्स का नाम arkvory न हो। जो सर्वर माउंट किए हुए वॉल्यूम के साथ पहले से क्लस्टर को सेवा दे रहा है उस पर (पहले cluster-release से वॉल्यूम छोड़ें), और जब Pacemaker Arkvory समूह का प्रबंधन करता है तब, यह अस्वीकार कर देता है, क्योंकि तब वॉल्यूम क्लस्टर का होता है: चल रहे क्लस्टर में सर्वर सर्वर बदलें में बताए अनुसार जोड़ें। cluster-node सर्विस अकाउंट वही उपयोगकर्ता और समूह ID लेकर बनाता है जो पहले सर्वर पर हैं (वॉल्यूम की फ़ाइलें उन्हीं की हैं) और वही सेवाएँ इंस्टॉल करता है, जिनमें से कोई अपने आप शुरू नहीं होती। अगर कोई अकाउंट दूसरे ID के साथ पहले से मौजूद है, तो कमांड रुक जाता है और बताता है कि कौन-से ID सेट करने हैं। हर बार जब कोई सर्वर सक्रिय होता है, arkvory-units पहले सेवाएँ वॉल्यूम से लेता है, इसलिए सक्रिय सर्वर पर बाद में बदली गई सेटिंग्स (उदाहरण के लिए बैकअप स्टोरेज) फ़ेलओवर के बाद भी लागू रहती हैं।

8. डेटा सर्वरों पर pcs से Corosync क्लस्टर सेट करें (pcs host auth, pcs cluster setup, pcs cluster start --all)। Debian और Ubuntu पर पहले हर डेटा सर्वर पर pcs cluster destroy चलाएँ: पैकेज एक नमूना Corosync कॉन्फ़िगरेशन इंस्टॉल करते हैं जिसे pcs मौजूदा क्लस्टर समझ लेता है। pcs cluster enable न चलाएँ: जो सर्वर फ़ेंस किया गया हो, वह तभी दोबारा जुड़े जब आप उसे शुरू करें। ha-2 के लिए विटनेस को भी ऑथेंटिकेट करें और उस पर pcs qdevice setup model net --enable --start चलाएँ। Debian और Ubuntu पर पैकेज ने कोरम डिवाइस अपने सर्विस अकाउंट के लिए पहले ही सेट कर दिया है: वहाँ इसके बजाय systemctl enable --now corosync-qnetd चलाएँ।

9. /root/arkvory-plan/pacemaker.sh खोलें। हर <agent parameters: …> को अपने फ़ेंस डिवाइस के पैरामीटर से बदलें: उसका पता, लॉगिन, पासवर्ड फ़ाइल या कुंजी, और उस सर्वर का प्लग या पोर्ट। फिर स्क्रिप्ट को एक डेटा सर्वर पर चलाएँ:

   sh /root/arkvory-plan/pacemaker.sh

   स्क्रिप्ट पूरा कॉन्फ़िगरेशन एक फ़ाइल में बनाती है और उसे एक साथ लागू करती है: फ़ेंसिंग, कोरम नीति, DRBD रिसोर्स, Arkvory समूह और उसकी बाधाएँ।

10. सक्रिय सर्वर पर क्लस्टर जाँचें:

    arkvory cluster-check --root /opt/proanima-arkvory

    कमांड कोरम, फ़ेंसिंग के चालू होने, हर सर्वर के पास फ़ेंस डिवाइस होने, DRBD की कोरम और फ़ेंसिंग सेटिंग, कम से कम दो कॉपी के पूरे होने और Arkvory के ठीक एक सर्वर पर चलने की जाँच करता है। कोई जाँच विफल हो तो यह त्रुटि के साथ बाहर निकलता है।

11. फ़ेंसिंग को एक बार प्रमाणित करें: हर स्टैंडबाय सर्वर को फ़ेंस करें और उसे लौटने दें (फ़ेंसिंग परीक्षण देखें)।

अपने क्लाइंट और DNS नाम को वर्चुअल पते पर पॉइंट करें।

रोज़मर्रा का संचालन

इन कमांड को root के रूप में चलाएँ। cluster-status, cluster-single-copy और cluster-kit वॉल्यूम पढ़ती हैं, इसलिए इन्हें सक्रिय सर्वर पर चलाएँ; cluster-check, cluster-switchover और cluster-fence-test किसी भी डेटा सर्वर पर काम करती हैं।

कमांड	क्या करता है
arkvory cluster-status --root <dir>	प्रोफ़ाइल, इस सर्वर की भूमिका, पूरी और ज़रूरी कॉपी और कोई भी ऑपरेटर निर्णय, JSON के रूप में
arkvory cluster-check --root <dir>	स्वस्थ क्लस्टर की सारी जाँचें; कोई विफल हो तो त्रुटि के साथ बाहर निकलता है
arkvory cluster-switchover --root <dir> --to <server>	Arkvory का दूसरे डेटा सर्वर पर नियोजित स्थानांतरण; जब तक लक्ष्य सर्वर के पास पूरी कॉपी न हो, अस्वीकार
arkvory cluster-fence-test --root <dir> --node <standby> [--yes]	स्टैंडबाय सर्वर को फ़ेंस करके उसके फ़ेंस डिवाइस को प्रमाणित करता है; सक्रिय सर्वर अस्वीकार
arkvory cluster-single-copy --root <dir> --until <time> --reason <text>	किसी समय तक एक कॉपी के साथ राइट स्वीकार करता है; एकल कॉपी देखें
arkvory cluster-kit --root <dir> --output <file>	सक्रिय सर्वर पर: वह फ़ाइल जो नए सर्वर को जुड़ने के लिए चाहिए; सर्वर बदलें देखें
arkvory cluster-node --root <dir> --kit <file>	नए सर्वर पर: वॉल्यूम लिए बिना उस फ़ाइल से उसे जोड़ता है

pcs status क्लस्टर को वैसा दिखाता है जैसा Pacemaker उसे देखता है।

कंसोल में

क्लस्टर इंस्टॉलेशन के मेनू में व्यवस्थापकों को क्लस्टर मिलता है। पेज लेआउट, अभी सेवा दे रहा सर्वर, पूरी कॉपी, राइट स्वीकार हो रही हैं या नहीं, और हर दूसरे सर्वर को उसके कनेक्शन और उसकी कॉपी (पूर्ण, बराबरी पर आ रही है या मौजूद नहीं) के साथ दिखाता है। नीचे अगला कदम वर्तमान स्थिति के अनुरूप एक कदम उसके कमांड के साथ देता है: सब कुछ पूरा होने पर नियोजित स्विचओवर, कॉपी गायब होने पर सर्वर को वापस लाना या बदलना (ha-3 में भी, जब राइट दो कॉपी के साथ जारी रहती हैं), और एकल-कॉपी निर्णय को कैसे ख़त्म करें। पेज हर 15 सेकंड में अपने आप रीफ़्रेश होता है।

जब राइट रुक जाती हैं, तो हर स्क्रीन पर एक बैनर यह बताता है; व्यवस्थापक उससे पेज खोल सकते हैं। प्रशासन अधिकार के बिना लोग केवल यह देखते हैं कि अपलोड रुके हुए हैं जबकि डाउनलोड काम करते रहते हैं।

नियोजित स्विचओवर

cluster-switchover Pacemaker से समूह को स्थानांतरित करने को कहता है, Arkvory के लक्ष्य पर चलने तक अधिकतम 5 मिनट प्रतीक्षा करता है और फिर अस्थायी प्लेसमेंट नियम हटा देता है। जब तक लक्ष्य के पास अपनी पूरी कॉपी नहीं होती, उदाहरण के लिए जब वह री-सिंक्रोनाइज़ हो रहा हो, तब तक यह अस्वीकार किया जाता है। स्थानांतरण के दौरान पुराने सर्वर के कनेक्शन टूटते हैं; क्लाइंट अपने अनुरोध दोहराते हैं। Arkvory कभी अपने आप वापस नहीं जाता।

फ़ेंसिंग परीक्षण

cluster-fence-test पहले cluster-check की जाँचें चलाता है और कोई विफल हो तो अस्वीकार कर देता है। ha-2 में इकलौते स्टैंडबाय को फ़ेंस करने से उसके लौटने तक राइट रुक जाती हैं, इसलिए कमांड --yes भी माँगता है। यह स्टैंडबाय सर्वर को उसके फ़ेंस डिवाइस के ज़रिए रीस्टार्ट करता है। रीस्टार्ट के बाद उस सर्वर पर pcs cluster start से क्लस्टर शुरू करें। क्लस्टर सेवाएँ रीस्टार्ट के बाद अपने आप शुरू नहीं होतीं (क्लस्टर बनाएँ का चरण 8), इसलिए फ़ेंस किया गया सर्वर आपके बिना कभी दोबारा नहीं जुड़ता।

अपडेट

हर डेटा सर्वर पर नया पैकेज इंस्टॉल करें। स्टैंडबाय सर्वरों पर पैकेज केवल प्रोग्राम फ़ाइलें बदलता है, क्योंकि रिलीज़ वॉल्यूम पर रहती है। सक्रिय सर्वर पर पैकेज रिलीज़ लागू करता है: Arkvory Pacemaker को समूह को न छेड़ने के लिए कहता है, सेवाएँ रोकता है, माइग्रेट करता है, उन्हें शुरू करता है, उनके तैयार होने तक प्रतीक्षा करता है और समूह लौटा देता है। स्वचालित अपडेट सक्रिय सर्वर पर इसी तरह काम करते हैं। अगर अपडेट और उसका रोलबैक दोनों विफल हो जाते हैं, तो समूह अप्रबंधित रहता है और Pacemaker फ़ेलओवर नहीं करता: कारण ठीक करें, फिर pcs resource cleanup arkvory और pcs resource manage arkvory चलाएँ।

क्लस्टर सर्वर पर systemctl से Arkvory सेवाएँ शुरू या बंद न करें। Pacemaker इसे विफलता मानेगा। पूरी सेवा को नियोजित रूप से रोकने के लिए pcs resource disable arkvory और pcs resource enable arkvory का उपयोग करें।

विफलताएँ

क्या होता है	ha-2	ha-3
एक स्टैंडबाय सर्वर विफल होता है	फ़ेंस किया जाता है। रीड जारी रहती हैं, राइट को 503 replication_degraded मिलता है	फ़ेंस किया जाता है। रीड और राइट जारी रहती हैं
सक्रिय सर्वर विफल होता है	फ़ेंस किया जाता है, Arkvory दूसरे सर्वर पर शुरू होता है। रीड लौट आती हैं, राइट दूसरी कॉपी की प्रतीक्षा करती हैं	फ़ेंस किया जाता है, Arkvory दूसरे सर्वर पर शुरू होता है। रीड और राइट लौट आती हैं
डेटा सर्वरों के बीच नेटवर्क विभाजन	विटनेस एक पक्ष को कोरम देता है; दूसरा पक्ष फ़ेंस होता है। कभी दो राइटर नहीं	बहुमत वाला पक्ष जारी रहता है; दूसरा सर्वर फ़ेंस होता है
तीन में से दो सदस्य विफल (ha-2: एक डेटा सर्वर और विटनेस)	आख़िरी सर्वर के पास कोरम नहीं: Arkvory रुक जाता है। कोरम के बिना कभी कोई राइटर नहीं। सर्वर वापस लाएँ (नीचे देखें)	दो डेटा सर्वरों के लिए भी यही
फ़ेंसिंग काम नहीं करती	कोई फ़ेलओवर नहीं। फ़ेंसिंग सफल होने तक Arkvory रुका रहता है	वही

फ़ेंस किए गए सर्वर को वापस लाने के लिए:

1. कारण ठीक करें और सर्वर शुरू करें।
2. उस पर pcs cluster start चलाएँ।
3. वॉल्यूम बदले हुए ब्लॉक को री-सिंक्रोनाइज़ करता है। जब आवश्यक हर कॉपी फिर पूरी हो जाती है, तो राइट अपने आप फिर शुरू हो जाती हैं; arkvory cluster-status प्रगति दिखाता है।

कोरम खोने के बाद, लौटे हुए हर सर्वर पर क्लस्टर शुरू करें। Pacemaker सबसे नई कॉपी वाले सर्वर पर Arkvory फिर चलाता है। जिस सर्वर ने कोरम आख़िर में खोया, वह लौटते समय एक बार फिर फ़ेंस हो सकता है, क्योंकि वह साफ़ तरीके से बंद नहीं हो पाया था: उसके रीस्टार्ट के बाद उस पर फिर से क्लस्टर शुरू करें।

जब फ़ेंसिंग विफल हुई हो और आपने उसे ठीक कर दिया हो, तो चल रहे सर्वर पर विफल प्रयास साफ़ करें ताकि Pacemaker फिर कोशिश करे: pcs stonith history cleanup <server> और pcs resource cleanup।

सर्वर बदलें

जब कोई डेटा सर्वर हमेशा के लिए खो जाए, तो उसे उसी नाम और पते वाले नए सर्वर से बदलें। Arkvory पूरे समय सक्रिय सर्वर पर सेवा देता रहता है; नई कॉपी पूरी होते ही राइट फिर शुरू हो जाती हैं।

1. नए सर्वर पर वही Linux डिस्ट्रीब्यूशन, DRBD, Pacemaker और फ़ेंस एजेंट इंस्टॉल करें, और Arkvory पैकेज का वही संस्करण अनपैक करें, जैसा क्लस्टर बनाएँ के चरण 1 में है। ha-2 के लिए corosync-qdevice भी इंस्टॉल करें।

2. सक्रिय सर्वर पर वह फ़ाइल लिखें जो नए सर्वर को चाहिए: रिसोर्स का नाम, सर्विस अकाउंट के ID और सेवाएँ।

   arkvory cluster-kit --root /opt/proanima-arkvory --output /root/arkvory-node.kit

   इसे सुरक्षित चैनल से नए सर्वर पर कॉपी करें। इसमें कोई रहस्य नहीं है, लेकिन यह क्लस्टर का वर्णन करती है।

3. नए सर्वर पर फ़ाइल के साथ जुड़ें। इसके लिए वॉल्यूम की ज़रूरत नहीं है:

   arkvory cluster-node --root /opt/proanima-arkvory --kit /root/arkvory-node.kit
   dpkg --configure proanima-arkvory   # केवल .deb

4. किसी दूसरे डेटा सर्वर से /etc/drbd.d/arkvory.res कॉपी करें, फिर मेटाडेटा बनाएँ और रिसोर्स चालू करें। नई कॉपी सक्रिय सर्वर से भरनी शुरू होती है:

   drbdadm create-md arkvory
   drbdadm up arkvory

5. क्लस्टर सदस्य बदलें: सक्रिय सर्वर पर pcs host auth <server>, pcs cluster node remove <server>, फिर pcs cluster node add <server> addr=<address> --start चलाएँ। अगर नया सर्वर उन्हीं डिवाइस सेटिंग्स पर उत्तर देता है, तो सर्वर का फ़ेंस डिवाइस अपना कॉन्फ़िगरेशन बनाए रखता है; अन्यथा उसे pcs stonith update से अपडेट करें।

6. कंसोल में क्लस्टर या arkvory cluster-status पर नज़र रखें: सर्वर अपनी कॉपी पूरी होने तक बराबरी पर आ रही है दिखाता है। फिर राइट अपने आप फिर शुरू हो जाती हैं।

7. नए सर्वर के फ़ेंस डिवाइस को arkvory cluster-fence-test --node <server> --yes से प्रमाणित करें, और arkvory cluster-check चलाएँ।

एकल कॉपी

जब कोई डेटा सर्वर लंबे समय तक दूर रहे (उदाहरण के लिए डिस्क बदलने के कारण) और रुकी हुई राइट का नुकसान जोखिम से ज़्यादा हो, तो ऑपरेटर सीमित समय के लिए एक कॉपी के साथ राइट स्वीकार कर सकता है:

arkvory cluster-single-copy --root /opt/proanima-arkvory --until 2026-10-12T18:00:00Z --reason "disk replacement on node-b"

• समय अगले 7 दिनों के भीतर होना चाहिए और उसमें उसका ज़ोन होना चाहिए: UTC के लिए Z या +03:00 जैसा ऑफ़सेट। ज़ोन के बिना कमांड अस्वीकार कर देता है, क्योंकि सक्रिय सर्वर उसे अपने स्थानीय समय में पढ़ेगा। कमांड केवल तब तक काम करता है जब तक कॉपी कम हैं।
• निर्णय सक्रिय रहते हुए सक्रिय सर्वर खो जाए, तो उसके बाद स्वीकृत राइट खो जाती हैं।
• कंसोल बैनर, मीट्रिक arkvory_replication_required_copies और अलर्ट ArkvorySingleCopyWrites निर्णय को दिखाते हैं।
• यह अपने समय पर, --off से, या हर कॉपी के फिर पूरी हो जाते ही अपने आप ख़त्म हो जाता है। बाद में कोई कॉपी खोने पर राइट फिर रुक जाती हैं।

मॉनिटरिंग

राइट रुकी होने पर भी सक्रिय सर्वर पर GET /health/ready 200 ही रहता है, ताकि मॉनिटर किसी स्वस्थ सर्वर को न हटाए। इसका फ़ील्ड writable false होता है और फ़ील्ड replication में copies, required और singleCopyUntil दिखते हैं; कॉपी पढ़ी न जा सकें तो replication null होता है। व्यवस्थापकों के लिए इसमें node (उत्तर देने वाला सर्वर), profile और peers भी होते हैं, यानी बाकी सर्वर अपने कनेक्शन और कॉपी के साथ, जिन्हें कंसोल पेज दिखाता है। स्टैंडअलोन सर्वरों में replication फ़ील्ड नहीं होता।

मीट्रिक	अर्थ
arkvory_replication_copies	पिछली जाँच पर पूरी कॉपी
arkvory_replication_required_copies	एक राइट के लिए ज़रूरी कॉपी: 2, या एकल-कॉपी निर्णय के दौरान 1
arkvory_replication_writes_refused_total	जिन राइट का उत्तर 503 replication_degraded से दिया गया
arkvory_replication_check_failures_total	कॉपी की स्थिति पढ़ने के विफल प्रयास

deploy/monitoring/arkvory-alerts.yml के अलर्ट नियमों में ArkvoryReplicationDegraded, ArkvorySingleCopyWrites और ArkvoryReplicationCheckFailing शामिल हैं। क्लस्टर पर भी नज़र रखें: arkvory cluster-check को नियमित अंतराल पर चलाएँ और उसके एग्ज़िट कोड पर अलर्ट करें, या अपने Pacemaker इंस्टॉलेशन की मॉनिटरिंग इस्तेमाल करें। मॉनिटरिंग देखें।

बैकअप

बैकअप एजेंट समूह के हिस्से के रूप में केवल सक्रिय सर्वर पर चलता है। बैकअप स्टोरेज (vault) को क्लस्टर वॉल्यूम के बाहर रखें, उदाहरण के लिए NAS पर। बैकअप देखें।