ກຸ່ມຂອງສອງຂໍ້ - ມານແມ່ນຢູ່ໃນລາຍລະອຽດ

Hey Habr! ຂ້າ​ພະ​ເຈົ້າ​ນໍາ​ສະ​ເຫນີ​ໃຫ້​ທ່ານ​ສົນ​ໃຈ​ການ​ແປ​ພາ​ສາ​ຂອງ​ບົດ​ຄວາມ​ໄດ້​ "ສອງຂໍ້ - ມານແມ່ນຢູ່ໃນລາຍລະອຽດ" ໂດຍ Andrew Beekhof.

ປະຊາຊົນຈໍານວນຫຼາຍມັກກຸ່ມສອງໂຫນດເພາະວ່າພວກເຂົາເບິ່ງຄືວ່າມີແນວຄວາມຄິດທີ່ງ່າຍດາຍແລະຍັງມີລາຄາຖືກກວ່າ 33% ລາຄາຖືກກວ່າຄູ່ຮ່ວມຂອງສາມໂຫນດ. ເຖິງແມ່ນວ່າມັນເປັນໄປໄດ້ທີ່ຈະເອົາກຸ່ມທີ່ດີຂອງສອງໂຫນດເຂົ້າກັນ, ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ເນື່ອງຈາກສະຖານະການທີ່ບໍ່ໄດ້ພິຈາລະນາ, ການຕັ້ງຄ່າດັ່ງກ່າວຈະສ້າງບັນຫາທີ່ບໍ່ຊັດເຈນຫຼາຍ.

ຂັ້ນຕອນທໍາອິດໃນການສ້າງລະບົບການມີໃຫ້ສູງແມ່ນເພື່ອຊອກຫາແລະພະຍາຍາມລົບລ້າງຈຸດຂອງຄວາມລົ້ມເຫຼວຂອງບຸກຄົນ, ມັກຈະຫຍໍ້ເປັນ. SPoF (ຈຸດດຽວຂອງຄວາມລົ້ມເຫຼວ).

ມັນເປັນມູນຄ່າທີ່ຈະຮັກສາຢູ່ໃນໃຈວ່າມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະລົບລ້າງຄວາມສ່ຽງທີ່ເປັນໄປໄດ້ທັງຫມົດຂອງ downtime ໃນລະບົບໃດຫນຶ່ງ. ນີ້ແມ່ນມາຈາກຄວາມຈິງທີ່ວ່າການປ້ອງກັນຄວາມສ່ຽງປົກກະຕິແມ່ນເພື່ອແນະນໍາການຊ້ໍາຊ້ອນບາງຢ່າງ, ເຊິ່ງນໍາໄປສູ່ຄວາມສັບສົນຂອງລະບົບທີ່ເພີ່ມຂຶ້ນແລະການເກີດຂື້ນຂອງຈຸດໃຫມ່ຂອງຄວາມລົ້ມເຫຼວ. ດັ່ງນັ້ນ, ພວກເຮົາໃນເບື້ອງຕົ້ນເຮັດໃຫ້ການປະນີປະນອມແລະສຸມໃສ່ເຫດການທີ່ກ່ຽວຂ້ອງກັບຈຸດຂອງຄວາມລົ້ມເຫຼວຂອງບຸກຄົນ, ແລະບໍ່ແມ່ນກ່ຽວກັບຕ່ອງໂສ້ຂອງທີ່ກ່ຽວຂ້ອງແລະ, ດັ່ງນັ້ນ, ເຫດການທີ່ເປັນໄປໄດ້ຫນ້ອຍລົງ.

ເນື່ອງຈາກການລົງທືນ, ພວກເຮົາບໍ່ພຽງແຕ່ຊອກຫາ SPoF, ແຕ່ຍັງດຸ່ນດ່ຽງຄວາມສ່ຽງແລະຜົນສະທ້ອນ, ເປັນຜົນມາຈາກການສະຫລຸບຂອງສິ່ງທີ່ສໍາຄັນແລະສິ່ງທີ່ບໍ່ອາດຈະແຕກຕ່າງກັນສໍາລັບແຕ່ລະການປະຕິບັດ.

ບໍ່ແມ່ນທຸກຄົນຕ້ອງການຜູ້ສະຫນອງໄຟຟ້າທາງເລືອກທີ່ມີສາຍໄຟຟ້າເອກະລາດ. ເຖິງແມ່ນວ່າຄວາມວິຕົກກັງວົນໄດ້ຈ່າຍໃຫ້ລູກຄ້າຢ່າງຫນ້ອຍຫນຶ່ງຄົນໃນເວລາທີ່ການກວດສອບຂອງພວກເຂົາກວດພົບວ່າຫມໍ້ແປງທີ່ຜິດພາດ. ລູກ​ຄ້າ​ໄດ້​ໂທ​ຫາ​ໂທລະ​ສັບ​ພະ​ຍາ​ຍາມ​ເພື່ອ​ແຈ້ງ​ໃຫ້​ບໍ​ລິ​ສັດ​ພະ​ລັງ​ງານ​ຈົນ​ກ​່​ວາ​ຫມໍ້​ໄຟ​ທີ່​ຜິດ​ພາດ​ແຕກ​.

ຈຸດເລີ່ມຕົ້ນທໍາມະຊາດແມ່ນການມີຫຼາຍກວ່າຫນຶ່ງ node ໃນລະບົບ. ຢ່າງໃດກໍ່ຕາມ, ກ່ອນທີ່ລະບົບສາມາດຍ້າຍການບໍລິການໄປຫາໂຫນດທີ່ມີຊີວິດຢູ່ຫຼັງຈາກຄວາມລົ້ມເຫລວ, ໂດຍທົ່ວໄປແລ້ວມັນຈໍາເປັນຕ້ອງຮັບປະກັນວ່າການບໍລິການທີ່ຈະຖືກຍ້າຍໄປບ່ອນອື່ນບໍ່ມີການເຄື່ອນໄຫວ.

ບໍ່ມີຂໍ້ບົກຜ່ອງກັບກຸ່ມສອງໂຫນດຖ້າຄວາມລົ້ມເຫລວເຮັດໃຫ້ທັງສອງ nodes ໃຫ້ບໍລິການເວັບໄຊທ໌ຄົງທີ່ດຽວກັນ. ຢ່າງໃດກໍ່ຕາມ, ສິ່ງຕ່າງໆຈະປ່ຽນແປງຖ້າຜົນໄດ້ຮັບແມ່ນວ່າທັງສອງຝ່າຍສາມາດຈັດການແຖວວຽກຮ່ວມກັນເປັນເອກະລາດຫຼືສະຫນອງການເຂົ້າເຖິງການຂຽນແບບບໍ່ປະສານງານກັບຖານຂໍ້ມູນທີ່ເຮັດສໍາເນົາຫຼືລະບົບໄຟລ໌ທີ່ແບ່ງປັນ.

ດັ່ງນັ້ນ, ເພື່ອປ້ອງກັນການສໍ້ລາດບັງຫຼວງຂອງຂໍ້ມູນເປັນຜົນມາຈາກຄວາມລົ້ມເຫຼວຂອງ node ດຽວ - ພວກເຮົາອີງໃສ່ບາງສິ່ງບາງຢ່າງທີ່ເອີ້ນວ່າ "ຄວາມແຕກແຍກ" (ຮົ້ວ).

ຫຼັກການຂອງ dissociation

ຫົວໃຈຂອງຫຼັກການຂອງ dissociation ແມ່ນຄໍາຖາມ: node ແຂ່ງຂັນສາມາດເຮັດໃຫ້ເກີດຄວາມເສຍຫາຍຂໍ້ມູນ? ໃນກໍລະນີທີ່ຂໍ້ມູນສໍ້ລາດບັງຫຼວງແມ່ນສະຖານະການທີ່ອາດຈະເປັນໄປໄດ້, ການແກ້ໄຂທີ່ດີຄືການແຍກ node ຈາກທັງຄໍາຮ້ອງຂໍຂາເຂົ້າແລະການເກັບຮັກສາຢ່າງຕໍ່ເນື່ອງ. ວິທີການທົ່ວໄປທີ່ສຸດສໍາລັບການ disassociation ແມ່ນເພື່ອ disconnect nodes faulty.

ມີສອງປະເພດຂອງວິທີການ dissociation, ທີ່ຂ້າພະເຈົ້າຈະໂທຫາ ຊື່ и ທາງອ້ອມ, ແຕ່ພວກເຂົາສາມາດເອີ້ນໄດ້ເທົ່າທຽມກັນ ເຄື່ອນໄຫວ и ຕົວຕັ້ງຕົວຕີ. ວິທີການໂດຍກົງປະກອບມີການປະຕິບັດໃນສ່ວນຂອງເພື່ອນມິດທີ່ຍັງມີຊີວິດຢູ່, ເຊັ່ນການໂຕ້ຕອບກັບ IPMI (Intelligent Platform Management Interface) ຫຼື iLO (ກົນໄກການຄຸ້ມຄອງເຄື່ອງແມ່ຂ່າຍໃນເວລາທີ່ບໍ່ມີການເຂົ້າເຖິງທາງດ້ານຮ່າງກາຍຂອງພວກເຂົາ) ອຸປະກອນ, ໃນຂະນະທີ່ວິທີການທາງອ້ອມແມ່ນອີງໃສ່ຄວາມລົ້ມເຫລວ. node ເພື່ອຮັບຮູ້ບາງຢ່າງວ່າມັນຢູ່ໃນສະພາບທີ່ບໍ່ດີ (ຫຼືຢ່າງຫນ້ອຍປ້ອງກັນບໍ່ໃຫ້ສະມາຊິກອື່ນໆຟື້ນຕົວ) ແລະສັນຍານ. ເຝົ້າລະວັງຮາດແວ ກ່ຽວກັບຄວາມຕ້ອງການທີ່ຈະຕັດການເຊື່ອມຕໍ່ node ລົ້ມເຫລວ.

Quorum ຊ່ວຍໃນເວລາທີ່ໃຊ້ທັງວິທີການໂດຍກົງແລະທາງອ້ອມ.

dissociation ໂດຍກົງ

ໃນ​ກໍ​ລະ​ນີ​ຂອງ dissociation ໂດຍ​ກົງ​, ພວກ​ເຮົາ​ສາ​ມາດ​ນໍາ​ໃຊ້ quorum ເພື່ອ​ປ້ອງ​ກັນ​ການ dissociation races ໃນ​ກໍ​ລະ​ນີ​ທີ່​ເຄືອ​ຂ່າຍ​ລົ້ມ​ເຫຼວ​.

ດ້ວຍແນວຄວາມຄິດຂອງກຸ່ມ, ມີຂໍ້ມູນພຽງພໍໃນລະບົບ (ເຖິງແມ່ນວ່າບໍ່ໄດ້ເຊື່ອມຕໍ່ກັບເພື່ອນມິດຂອງຕົນ) ສໍາລັບ nodes ທີ່ຈະຮູ້ອັດຕະໂນມັດວ່າພວກເຂົາຄວນຈະເລີ່ມຕົ້ນ dissociation ແລະ / ຫຼືການຟື້ນຟູ.

ຖ້າບໍ່ມີກຸ່ມໂຄຣໍາ, ທັງສອງຝ່າຍຂອງການແບ່ງປັນເຄືອຂ່າຍຈະສົມມຸດຢ່າງຖືກຕ້ອງວ່າອີກຝ່າຍຫນຶ່ງຕາຍແລະຈະຊອກຫາວິທີທີ່ຈະແຍກອີກຝ່າຍຫນຶ່ງ. ໃນກໍລະນີທີ່ຮ້າຍແຮງທີ່ສຸດ, ທັງສອງຝ່າຍຈັດການປິດກຸ່ມທັງຫມົດ. ສະຖານະການທີ່ເປັນທາງເລືອກແມ່ນການຈັບຄູ່ຕາຍ, ຊ່ອງຫວ່າງທີ່ບໍ່ມີທີ່ສິ້ນສຸດຂອງການວາງໄຂ່, ບໍ່ເຫັນມິດສະຫາຍຂອງພວກເຂົາ, ການປິດເປີດພວກມັນຄືນໃຫມ່, ແລະການເລີ່ມຕົ້ນການຟື້ນຕົວພຽງແຕ່ເພື່ອ reboot ເມື່ອເພື່ອນມິດຂອງພວກເຂົາປະຕິບັດຕາມເຫດຜົນດຽວກັນ.

ບັນຫາກ່ຽວກັບການແຍກຕົວອອກແມ່ນວ່າອຸປະກອນທີ່ໃຊ້ທົ່ວໄປທີ່ສຸດບໍ່ສາມາດໃຊ້ໄດ້ເນື່ອງຈາກເຫດການຄວາມລົ້ມເຫລວດຽວກັນທີ່ພວກເຮົາຕ້ອງການເປົ້າຫມາຍການຟື້ນຕົວ. ບັດ IPMI ແລະ iLO ສ່ວນໃຫຍ່ຖືກຕິດຕັ້ງຢູ່ໃນໂຮດທີ່ພວກເຂົາຄວບຄຸມແລະ, ໂດຍຄ່າເລີ່ມຕົ້ນ, ໃຊ້ເຄືອຂ່າຍດຽວກັນ, ເຊິ່ງເຮັດໃຫ້ເຈົ້າພາບເປົ້າຫມາຍເຊື່ອວ່າໂຮດອື່ນແມ່ນອອບໄລນ໌.

ແຕ່ຫນ້າເສຍດາຍ, ລັກສະນະການເຮັດວຽກຂອງອຸປະກອນ IPMI ແລະ iLo ບໍ່ຄ່ອຍຖືກພິຈາລະນາໃນເວລາຊື້ອຸປະກອນ.

ການແຕກແຍກທາງອ້ອມ

Quorum ຍັງມີຄວາມສໍາຄັນສໍາລັບການຄຸ້ມຄອງການ disassociation ທາງອ້ອມ; ຖ້າເຮັດຢ່າງຖືກຕ້ອງ, ກຸ່ມສາມາດອະນຸຍາດໃຫ້ຜູ້ລອດຊີວິດສົມມຸດວ່າ nodes ທີ່ສູນເສຍຈະຫັນໄປສູ່ສະຖານະທີ່ປອດໄພຫຼັງຈາກໄລຍະເວລາທີ່ແນ່ນອນ.

ດ້ວຍການຕັ້ງຄ່ານີ້, ເຄື່ອງຈັບເວລາເຝົ້າລະວັງຂອງຮາດແວຈະຖືກຣີເຊັດທຸກໆ N ວິນາທີ ຖ້າກຸ່ມບໍ່ເສຍ. ຖ້າເຄື່ອງຈັບເວລາ (ປົກກະຕິແລ້ວຫຼາຍຕົວຄູນຂອງ N) ໝົດອາຍຸ, ອຸປະກອນດັ່ງກ່າວຈະປິດການໃຊ້ງານທີ່ບໍ່ເໝາະສົມ (ບໍ່ປິດ).

ວິທີການນີ້ແມ່ນມີປະສິດທິພາບຫຼາຍ, ແຕ່ຖ້າບໍ່ມີກຸ່ມ, ບໍ່ມີຂໍ້ມູນພຽງພໍພາຍໃນກຸ່ມເພື່ອຈັດການມັນ. ມັນບໍ່ງ່າຍທີ່ຈະບອກຄວາມແຕກຕ່າງລະຫວ່າງການຢຸດເຄືອຂ່າຍແລະຄວາມລົ້ມເຫຼວຂອງ peer node. ເຫດຜົນນີ້ແມ່ນຍ້ອນວ່າບໍ່ມີຄວາມສາມາດໃນການແຍກຄວາມແຕກຕ່າງລະຫວ່າງສອງກໍລະນີ, ທ່ານຖືກບັງຄັບໃຫ້ເລືອກເອົາພຶດຕິກໍາດຽວກັນໃນທັງສອງກໍລະນີ.

ບັນຫາໃນການເລືອກຮູບແບບຫນຶ່ງແມ່ນວ່າບໍ່ມີຫຼັກສູດການປະຕິບັດທີ່ເພີ່ມຄວາມພ້ອມແລະປ້ອງກັນການສູນເສຍຂໍ້ມູນ.

• ຖ້າທ່ານເລືອກທີ່ຈະສົມມຸດວ່າ peer node ມີການເຄື່ອນໄຫວແຕ່ໃນຄວາມເປັນຈິງບໍ່ສໍາເລັດ, ກຸ່ມຈະຢຸດເຊົາການບໍລິການທີ່ບໍ່ຈໍາເປັນທີ່ຈະດໍາເນີນການເພື່ອຊົດເຊີຍການສູນເສຍການບໍລິການຈາກ node peer ລົ້ມເຫລວ.
• ຖ້າທ່ານຕັດສິນໃຈທີ່ຈະສົມມຸດວ່າ node ຫຼຸດລົງ, ແຕ່ວ່າມັນເປັນພຽງແຕ່ຄວາມລົ້ມເຫຼວຂອງເຄືອຂ່າຍແລະໃນຄວາມເປັນຈິງ node ຫ່າງໄກສອກຫຼີກແມ່ນເຮັດວຽກ, ທີ່ດີທີ່ສຸດທີ່ທ່ານກໍາລັງລົງທະບຽນສໍາລັບການ reconciliation ຄູ່ມືໃນອະນາຄົດຂອງຊຸດຂໍ້ມູນຜົນໄດ້ຮັບ.

ໂດຍບໍ່ຄໍານຶງເຖິງສິ່ງທີ່ທ່ານໃຊ້ heuristic, ມັນເປັນເລື່ອງເລັກໆນ້ອຍໆທີ່ຈະສ້າງຄວາມລົ້ມເຫລວທີ່ຈະເຮັດໃຫ້ທັງສອງຝ່າຍລົ້ມເຫລວຫຼືເຮັດໃຫ້ cluster ປິດໂຫນດທີ່ມີຊີວິດຢູ່. ການບໍ່ໃຊ້ກຸ່ມໂຄຣຳຢ່າງແທ້ຈິງເຮັດໃຫ້ກຸ່ມຂອງເຄື່ອງມືທີ່ມີປະສິດທິພາບທີ່ສຸດໃນສານຫນູຂອງມັນ.

ຖ້າບໍ່ມີທາງເລືອກອື່ນ, ວິທີທີ່ດີທີ່ສຸດແມ່ນການເສຍສະລະຄວາມພ້ອມ (ໃນທີ່ນີ້ຜູ້ຂຽນຫມາຍເຖິງທິດສະດີ CAP). ຄວາມພ້ອມສູງຂອງຂໍ້ມູນທີ່ເສຍຫາຍບໍ່ໄດ້ຊ່ວຍໃຜ, ແລະການຄືນດີຊຸດຂໍ້ມູນຕ່າງໆດ້ວຍຕົນເອງກໍ່ບໍ່ມ່ວນຄືກັນ.

ກຸ່ມ

Quorum ຟັງໄດ້ດີ, ແມ່ນບໍ?

ຂໍ້ເສຍພຽງແຕ່ວ່າເພື່ອໃຫ້ມັນຢູ່ໃນກຸ່ມທີ່ມີສະມາຊິກ N, ທ່ານຈໍາເປັນຕ້ອງມີການເຊື່ອມຕໍ່ລະຫວ່າງ N / 2 + 1 ຂອງ nodes ຂອງທ່ານທີ່ຍັງເຫຼືອ. ເຊິ່ງເປັນໄປບໍ່ໄດ້ໃນສອງ node cluster ຫຼັງຈາກໜຶ່ງ node ລົ້ມເຫລວ.

ເຊິ່ງໃນທີ່ສຸດກໍ່ນໍາພວກເຮົາໄປສູ່ບັນຫາພື້ນຖານທີ່ມີສອງ nodes:
Quorum ບໍ່ມີຄວາມຫມາຍໃນສອງ node clusters, ແລະໂດຍບໍ່ມີມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະກໍານົດຢ່າງຫນ້າເຊື່ອຖືຂອງການປະຕິບັດທີ່ເພີ່ມຄວາມພ້ອມແລະປ້ອງກັນການສູນເສຍຂໍ້ມູນ.
ເຖິງແມ່ນວ່າຢູ່ໃນລະບົບຂອງສອງ nodes ທີ່ເຊື່ອມຕໍ່ໂດຍສາຍ crossover, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະຈໍາແນກໄດ້ຢ່າງຈະແຈ້ງລະຫວ່າງເຄືອຂ່າຍ outage ແລະຄວາມລົ້ມເຫຼວຂອງ node ອື່ນໆ. ການປິດການໃຊ້ງານຫນຶ່ງປາຍ (ຄວາມເປັນໄປໄດ້ຂອງມັນແມ່ນ, ແນ່ນອນ, ອັດຕາສ່ວນກັບໄລຍະຫ່າງລະຫວ່າງ nodes) ຈະພຽງພໍທີ່ຈະ invalidate ການສົມມຸດຕິຖານວ່າສຸຂະພາບຂອງການເຊື່ອມຕໍ່ແມ່ນເທົ່າກັບສຸຂະພາບຂອງ node ຄູ່ຮ່ວມງານ.

ເຮັດໃຫ້ກຸ່ມສອງໂຫນດເຮັດວຽກ

ບາງຄັ້ງລູກຄ້າບໍ່ສາມາດຫຼືບໍ່ຕ້ອງການຊື້ node ທີສາມ, ແລະພວກເຮົາຖືກບັງຄັບໃຫ້ຊອກຫາທາງເລືອກ.

ທາງເລືອກ 1 - ວິທີການແຍກຕົວຊໍ້າກັນ

ອຸປະກອນ iLO ຫຼື IPMI ຂອງ node ສະແດງເຖິງຈຸດຂອງຄວາມລົ້ມເຫຼວເພາະວ່າ, ຖ້າມັນລົ້ມເຫລວ, ຜູ້ລອດຊີວິດບໍ່ສາມາດໃຊ້ມັນເພື່ອນໍາ node ໄປສູ່ສະຖານະທີ່ປອດໄພ. ໃນກຸ່ມຂອງ 3 ຫຼືຫຼາຍກວ່ານັ້ນ, ພວກເຮົາສາມາດຫຼຸດຜ່ອນການນີ້ໂດຍການຄິດໄລ່ກຸ່ມ ແລະໃຊ້ອຸປະກອນເຝົ້າລະວັງ (ກົນໄກການແຍກຕົວໂດຍທາງອ້ອມ, ດັ່ງທີ່ໄດ້ກ່າວມາກ່ອນໜ້ານີ້). ໃນກໍລະນີຂອງສອງ nodes, ພວກເຮົາຕ້ອງໃຊ້ຫນ່ວຍກະຈາຍພະລັງງານເຄືອຂ່າຍ (PDUs) ແທນ.

ຫຼັງຈາກຄວາມລົ້ມເຫລວ, ຜູ້ລອດຊີວິດທໍາອິດພະຍາຍາມຕິດຕໍ່ກັບອຸປະກອນ disassociation ຕົ້ນຕໍ (ຝັງ iLO ຫຼື IPMI). ຖ້າອັນນີ້ປະສົບຜົນສໍາເລັດ, ການຟື້ນຕົວຍັງສືບຕໍ່ເປັນປົກກະຕິ. ພຽງ​ແຕ່​ຖ້າ​ຫາກ​ວ່າ​ອຸ​ປະ​ກອນ iLO/IPMI ບໍ່​ສໍາ​ເລັດ​ແມ່ນ PDU ເຂົ້າ​ເຖິງ​; ຖ້າ​ຫາກ​ວ່າ​ການ​ເຂົ້າ​ເຖິງ​ສົບ​ຜົນ​ສໍາ​ເລັດ​, ການ​ຟື້ນ​ຟູ​ສາ​ມາດ​ສືບ​ຕໍ່​ໄດ້​.

ໃຫ້ແນ່ໃຈວ່າຈະວາງ PDU ໃນເຄືອຂ່າຍທີ່ແຕກຕ່າງກັນກ່ວາການຈາລະຈອນຂອງກຸ່ມ, ຖ້າບໍ່ດັ່ງນັ້ນຄວາມລົ້ມເຫຼວຂອງເຄືອຂ່າຍດຽວຈະຂັດຂວາງການເຂົ້າເຖິງທັງສອງອຸປະກອນ disassociation ແລະຕັນການຟື້ນຟູການບໍລິການ.

ໃນທີ່ນີ້ທ່ານອາດຈະຖາມ - PDU ເປັນຈຸດດຽວຂອງຄວາມລົ້ມເຫຼວບໍ? ເຊິ່ງຄໍາຕອບແມ່ນ, ແນ່ນອນ, ມັນແມ່ນ.

ຖ້າຄວາມສ່ຽງນີ້ແມ່ນສໍາຄັນສໍາລັບທ່ານ, ທ່ານບໍ່ໄດ້ຢູ່ຄົນດຽວ: ເຊື່ອມຕໍ່ທັງສອງ nodes ກັບສອງ PDUs ແລະບອກຊອບແວ clustering ໃຫ້ໃຊ້ທັງສອງໃນເວລາທີ່ເປີດແລະປິດ nodes. ດຽວນີ້ກຸ່ມຍັງເຮັດວຽກຢູ່ຖ້າ PDU ໂຕໜຶ່ງຕາຍ, ແລະຄວາມລົ້ມເຫຼວທີສອງຂອງ PDU ອື່ນ ຫຼືອຸປະກອນ IPMI ຈະຈໍາເປັນຕ້ອງໄດ້ສະກັດກັ້ນການຟື້ນຕົວ.

ທາງ​ເລືອກ 2 - ການ​ເພີ່ມ Arbiter ເປັນ​

ໃນບາງສະຖານະການ, ໃນຂະນະທີ່ວິທີການ disassociation ທີ່ຊ້ໍາກັນແມ່ນເປັນໄປໄດ້ທາງດ້ານເຕັກນິກ, ມັນມີຄວາມຫຍຸ້ງຍາກທາງດ້ານການເມືອງ. ຫຼາຍໆບໍລິສັດຢາກມີການແບ່ງແຍກກັນລະຫວ່າງຜູ້ບໍລິຫານແລະເຈົ້າຂອງແອັບພລິເຄຊັນ, ແລະຜູ້ບໍລິຫານເຄືອຂ່າຍທີ່ມີສະຕິຄວາມປອດໄພແມ່ນບໍ່ກະຕືລືລົ້ນສະເຫມີທີ່ຈະແບ່ງປັນການຕັ້ງຄ່າການເຂົ້າເຖິງ PDU ກັບໃຜ.

ໃນກໍລະນີນີ້, ທາງເລືອກທີ່ແນະນໍາແມ່ນການສ້າງພາກສ່ວນທີສາມທີ່ເປັນກາງທີ່ສາມາດເສີມການຄິດໄລ່ຂອງກຸ່ມ.

ໃນ​ກໍ​ລະ​ນີ​ຂອງ​ຄວາມ​ລົ້ມ​ເຫຼວ​, node ຕ້ອງ​ສາ​ມາດ​ເບິ່ງ airwaves ຂອງ​ຫມູ່​ເພື່ອນ​ຫຼື​ຜູ້​ຕັດ​ສິນ​ຂອງ​ຕົນ​ເພື່ອ​ຟື້ນ​ຟູ​ການ​ບໍ​ລິ​ການ​. arbiter ຍັງປະກອບມີຟັງຊັນຕັດການເຊື່ອມຕໍ່ຖ້າຫາກວ່າທັງສອງ nodes ສາມາດເບິ່ງ arbiter ໄດ້ແຕ່ບໍ່ສາມາດເຫັນເຊິ່ງກັນແລະກັນ.

ຕົວເລືອກນີ້ຈະຕ້ອງຖືກໃຊ້ຮ່ວມກັບວິທີການແຍກຕົວອອກໂດຍທາງອ້ອມ ເຊັ່ນ: ເຄື່ອງຈັບເວລາເຝົ້າລະວັງຂອງຮາດແວ, ເຊິ່ງຖືກຕັ້ງຄ່າເພື່ອຂ້າເຄື່ອງຈັກຫາກມັນສູນເສຍການເຊື່ອມຕໍ່ກັບໂນດມິດສະຫາຍ ແລະ arbiter node. ດັ່ງນັ້ນ, ຜູ້ລອດຊີວິດສາມາດສົມມຸດຕິຖານຢ່າງສົມເຫດສົມຜົນວ່າ node peer ຂອງມັນຈະຢູ່ໃນສະຖານະທີ່ປອດໄພຫຼັງຈາກໂມງຈັບເວລາຂອງຮາດແວຫມົດອາຍຸ.

ຄວາມແຕກຕ່າງໃນການປະຕິບັດລະຫວ່າງ arbiter ແລະ node ທີສາມແມ່ນວ່າ arbiter ຕ້ອງການຊັບພະຍາກອນຫນ້ອຍກວ່າທີ່ຈະດໍາເນີນການແລະສາມາດໃຫ້ບໍລິການຫຼາຍກ່ວາຫນຶ່ງກຸ່ມ.

ທາງເລືອກ 3 - ປັດໃຈຂອງມະນຸດ

ວິທີການສຸດທ້າຍແມ່ນເພື່ອໃຫ້ຜູ້ລອດຊີວິດສືບຕໍ່ດໍາເນີນການບໍລິການໃດກໍ່ຕາມທີ່ເຂົາເຈົ້າໄດ້ແລ່ນຢູ່ແລ້ວ, ແຕ່ບໍ່ເລີ່ມຕົ້ນໃຫມ່ຈົນກ່ວາບັນຫາຈະແກ້ໄຂໄດ້ເອງ (ການຟື້ນຟູເຄືອຂ່າຍ, ໂຫນດ reboot) ຫຼືບຸກຄົນໃດຫນຶ່ງຮັບຜິດຊອບສໍາລັບການຢັ້ງຢືນດ້ວຍຕົນເອງວ່າອີກດ້ານຫນຶ່ງແມ່ນຕາຍ.

ທາງເລືອກໂບນັດ

ຂ້ອຍບອກວ່າເຈົ້າສາມາດເພີ່ມຂໍ້ທີສາມໄດ້ບໍ?

ສອງ rack

ສໍາລັບເຫດຜົນຂອງການໂຕ້ຖຽງ, ໃຫ້ສົມມຸດວ່າຂ້ອຍໄດ້ຊັກຊວນເຈົ້າກ່ຽວກັບຄຸນງາມຄວາມດີຂອງຂໍ້ທີສາມ, ຕອນນີ້ພວກເຮົາຕ້ອງພິຈາລະນາການຈັດລຽງທາງດ້ານຮ່າງກາຍຂອງຂໍ້. ຖ້າພວກມັນຖືກຈັດໃສ່ (ແລະພະລັງງານ) ໃນ rack ດຽວກັນ, ນີ້ກໍ່ປະກອບເປັນ SPoF, ແລະອັນທີ່ບໍ່ສາມາດແກ້ໄຂໄດ້ໂດຍການເພີ່ມ rack ທີສອງ.

ຖ້າມັນເປັນເລື່ອງແປກທີ່, ພິຈາລະນາສິ່ງທີ່ຈະເກີດຂື້ນຖ້າ rack ທີ່ມີສອງ nodes ລົ້ມເຫລວ, ແລະວິທີ node ທີ່ມີຊີວິດຢູ່ຈະແຕກຕ່າງກັນລະຫວ່າງຄວາມລົ້ມເຫຼວຂອງເຄືອຂ່າຍ.

ຄໍາຕອບສັ້ນແມ່ນວ່າມັນເປັນໄປບໍ່ໄດ້, ແລະອີກເທື່ອຫນຶ່ງພວກເຮົາກໍາລັງຈັດການກັບບັນຫາທັງຫມົດໃນກໍລະນີສອງໂຫນດ. ຫຼືຜູ້ລອດຊີວິດ:

• ignoring quorum ແລະບໍ່ຖືກຕ້ອງທີ່ຈະລິເລີ່ມການຟື້ນຟູໃນໄລຍະເຄືອຂ່າຍ outs (ຄວາມສາມາດໃນການສໍາເລັດ dissociation ແມ່ນເລື່ອງທີ່ແຕກຕ່າງກັນແລະຂຶ້ນກັບວ່າ PDU ມີສ່ວນຮ່ວມແລະວ່າພວກເຂົາເຈົ້າແບ່ງປັນອໍານາດກັບ racks ໃດ), ຫຼື.
• ເຄົາລົບກຸ່ມໂຄຣຳ ແລະຕັດການເຊື່ອມຕໍ່ຕົວມັນເອງກ່ອນໄວອັນຄວນ ເມື່ອ node peer ລົ້ມເຫລວ

ໃນກໍລະນີໃດກໍ່ຕາມ, ສອງ rack ບໍ່ດີກວ່າຫນຶ່ງ, ແລະ nodes ຕ້ອງໄດ້ຮັບການສະຫນອງພະລັງງານເອກະລາດຫຼືຖືກແຈກຢາຍໃນທົ່ວສາມ (ຫຼືຫຼາຍກວ່ານັ້ນ, ຂຶ້ນກັບຈໍານວນໂຫນດທີ່ທ່ານມີ) racks.

ສອງສູນຂໍ້ມູນ

ໃນຈຸດນີ້, ຜູ້ອ່ານຜູ້ທີ່ບໍ່ມີຄວາມສ່ຽງຕໍ່ຄວາມສ່ຽງອາດຈະຕ້ອງການພິຈາລະນາການຟື້ນຟູໄພພິບັດ. ຈະເກີດຫຍັງຂຶ້ນເມື່ອດາວເຄາະນ້ອຍຕົກໃສ່ສູນຂໍ້ມູນດຽວກັນກັບສາມໂນດຂອງພວກເຮົາທີ່ແຜ່ລາມໄປທົ່ວສາມ racks ທີ່ແຕກຕ່າງກັນ? ແນ່ນອນສິ່ງທີ່ບໍ່ດີ, ແຕ່ຂຶ້ນກັບຄວາມຕ້ອງການຂອງທ່ານ, ການເພີ່ມສູນຂໍ້ມູນທີສອງອາດຈະບໍ່ພຽງພໍ.

ຖ້າເຮັດຢ່າງຖືກຕ້ອງ, ສູນຂໍ້ມູນທີສອງຈະໃຫ້ທ່ານ (ແລະສົມເຫດສົມຜົນ) ດ້ວຍສໍາເນົາທີ່ທັນສະໄຫມແລະສອດຄ່ອງຂອງການບໍລິການຂອງທ່ານແລະຂໍ້ມູນຂອງພວກເຂົາ. ຢ່າງໃດກໍຕາມ, ໃນສະຖານະການສອງໂຫນດ, ສອງ rack, ບໍ່ມີຂໍ້ມູນພຽງພໍໃນລະບົບເພື່ອຮັບປະກັນຄວາມພ້ອມສູງສຸດແລະປ້ອງກັນການສໍ້ລາດບັງຫຼວງ (ຫຼືຄວາມແຕກຕ່າງຂອງຊຸດຂໍ້ມູນ). ເຖິງແມ່ນວ່າມີສາມໂຫນດ (ຫຼື racks), ການແຈກຢາຍພວກມັນໃນທົ່ວສູນຂໍ້ມູນພຽງແຕ່ສອງສູນເຮັດໃຫ້ລະບົບບໍ່ສາມາດຕັດສິນໃຈທີ່ຖືກຕ້ອງໄດ້ໃນກໍລະນີທີ່ມີເຫດການ (ໃນປັດຈຸບັນຫຼາຍຂື້ນ) ທີ່ທັງສອງຝ່າຍບໍ່ສາມາດສື່ສານໄດ້.

ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າການແກ້ໄຂສູນຂໍ້ມູນຄູ່ແມ່ນບໍ່ເຄີຍເຫມາະສົມ. ບໍລິສັດມັກຈະຕ້ອງການໃຫ້ບຸກຄົນທີ່ຈະຮູ້ກ່ອນທີ່ຈະດໍາເນີນຂັ້ນຕອນພິເສດຂອງການເຄື່ອນຍ້າຍໄປຫາສູນຂໍ້ມູນສໍາຮອງ. ພຽງແຕ່ຈື່ໄວ້ວ່າຖ້າທ່ານຕ້ອງການເຮັດໃຫ້ການດັບໄຟອັດຕະໂນມັດ, ທ່ານຈະຕ້ອງມີສູນຂໍ້ມູນທີສາມສໍາລັບກຸ່ມເພື່ອໃຫ້ມີຄວາມຮູ້ສຶກ (ບໍ່ວ່າຈະໂດຍກົງຫຼືຜ່ານຜູ້ຕັດສິນ), ຫຼືເຈົ້າຈະຊອກຫາວິທີທີ່ຈະປິດຂໍ້ມູນທັງຫມົດຢ່າງຫນ້າເຊື່ອຖື. ກາງ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com