ເຄື່ອງຈັກ AERODISK: ຄວາມຕ້ານທານກັບໄພພິບັດ. ພາກທີ 1

ສະບາຍດີ, ຜູ້ອ່ານ Habr! ຫົວຂໍ້ຂອງບົດຄວາມນີ້ຈະເປັນການປະຕິບັດເຄື່ອງມືການຟື້ນຟູໄພພິບັດໃນລະບົບການເກັບຮັກສາເຄື່ອງຈັກ AERODISK. ໃນເບື້ອງຕົ້ນ, ພວກເຮົາຕ້ອງການຂຽນໃນບົດຄວາມຫນຶ່ງກ່ຽວກັບເຄື່ອງມືທັງສອງ: replication ແລະ metrocluster, ແຕ່ຫນ້າເສຍດາຍ, ບົດຄວາມໄດ້ຫັນອອກຍາວເກີນໄປ, ດັ່ງນັ້ນພວກເຮົາແບ່ງບົດຄວາມອອກເປັນສອງສ່ວນ. ໃຫ້ໄປຈາກງ່າຍດາຍໄປຫາສະລັບສັບຊ້ອນ. ໃນບົດຄວາມນີ້, ພວກເຮົາຈະຕັ້ງຄ່າແລະທົດສອບການຈໍາລອງແບບ synchronous - ພວກເຮົາຈະລຸດລົງສູນຂໍ້ມູນຫນຶ່ງ, ແລະຍັງທໍາລາຍຊ່ອງທາງການສື່ສານລະຫວ່າງສູນຂໍ້ມູນແລະເບິ່ງວ່າມີຫຍັງເກີດຂື້ນ.

ລູກຄ້າຂອງພວກເຮົາມັກຈະຖາມພວກເຮົາຄໍາຖາມຕ່າງໆກ່ຽວກັບການຈໍາລອງແບບຈໍາລອງ, ດັ່ງນັ້ນກ່ອນທີ່ຈະກ້າວໄປສູ່ການຕັ້ງຄ່າແລະການທົດສອບການປະຕິບັດການຈໍາລອງແບບຈໍາລອງ, ພວກເຮົາຈະບອກທ່ານເລັກນ້ອຍກ່ຽວກັບວ່າການຈໍາລອງການຈໍາລອງແມ່ນຫຍັງ.

ບິດຂອງທິດສະດີ

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

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

ຂໍ້ດີຂອງວິທີການນີ້:

• ຂໍ້ມູນແມ່ນຄືກັນໃນທຸກລະບົບການເກັບຮັກສາ

Cons:

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

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

ຂໍ້​ດີ​ຂອງ​ການ​ຈໍາ​ລອງ​ແບບ asynchronous​:

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

Cons:

• ຂໍ້ມູນໃນສູນຂໍ້ມູນທີ່ແຕກຕ່າງກັນແມ່ນບໍ່ຄືກັນ

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

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

ນອກຈາກນັ້ນ, ເລື້ອຍໆ, ເມື່ອພວກເຮົາເວົ້າກ່ຽວກັບການຈໍາລອງໂດຍໃຊ້ລະບົບການເກັບຮັກສາ, ຫຼາຍໆຄົນມີຄໍາຖາມທີ່ສົມເຫດສົມຜົນ: > "ຄໍາຮ້ອງສະຫມັກຈໍານວນຫຼາຍມີເຄື່ອງມືການຈໍາລອງຂອງຕົນເອງ, ເປັນຫຍັງຈຶ່ງໃຊ້ການຈໍາລອງໃນລະບົບການເກັບຮັກສາ? ມັນດີກວ່າຫຼືຮ້າຍແຮງກວ່າເກົ່າ?

ບໍ່ມີຄໍາຕອບທີ່ຊັດເຈນຢູ່ທີ່ນີ້, ດັ່ງນັ້ນນີ້ແມ່ນການໂຕ້ຖຽງ FOR ແລະ CONS:

Arguments ສຳລັບການຈຳລອງບ່ອນເກັບມ້ຽນ:

• ຄວາມງ່າຍດາຍຂອງການແກ້ໄຂ. ດ້ວຍເຄື່ອງມືດຽວ, ທ່ານສາມາດເຮັດຊ້ໍາຊຸດຂໍ້ມູນທັງຫມົດຂອງທ່ານ, ໂດຍບໍ່ຄໍານຶງເຖິງປະເພດຂອງການໂຫຼດແລະຄໍາຮ້ອງສະຫມັກ. ຖ້າທ່ານໃຊ້ replica ຈາກແອັບພລິເຄຊັນ, ທ່ານຈະຕ້ອງຕັ້ງຄ່າແຕ່ລະແອັບພລິເຄຊັນແຍກຕ່າງຫາກ. ຖ້າມີຫຼາຍກວ່າ 2 ຂອງພວກເຂົາ, ນີ້ແມ່ນໃຊ້ແຮງງານຫຼາຍແລະມີລາຄາແພງ (ການສະຫມັກແບບຈໍາລອງມັກຈະຕ້ອງມີໃບອະນຸຍາດແຍກຕ່າງຫາກແລະບໍ່ແມ່ນຟຣີສໍາລັບແຕ່ລະຄໍາຮ້ອງສະຫມັກ. ແຕ່ມີຫຼາຍກວ່ານັ້ນຂ້າງລຸ່ມນີ້).
• ທ່ານສາມາດ replicate ສິ່ງໃດ - ຄໍາຮ້ອງສະຫມັກໃດກໍ່ຕາມ, ຂໍ້ມູນໃດໆ - ແລະມັນຈະສອດຄ່ອງສະເຫມີ. ແອັບພລິເຄຊັນຈໍານວນຫຼາຍ (ສ່ວນໃຫຍ່) ບໍ່ມີຄວາມສາມາດໃນການຈໍາລອງ, ແລະການຈໍາລອງຈາກລະບົບການເກັບຮັກສາແມ່ນວິທີດຽວທີ່ຈະໃຫ້ການປົກປ້ອງຈາກໄພພິບັດ.
• ບໍ່ຈໍາເປັນຕ້ອງຈ່າຍເກີນສໍາລັບການທໍາງານຂອງການຈໍາລອງຄໍາຮ້ອງສະຫມັກ. ຕາມກົດລະບຽບ, ມັນບໍ່ແມ່ນລາຄາຖືກ, ຄືກັນກັບໃບອະນຸຍາດສໍາລັບການຈໍາລອງລະບົບການເກັບຮັກສາ. ແຕ່ທ່ານຕ້ອງຈ່າຍສໍາລັບໃບອະນຸຍາດສໍາລັບການ replication ການເກັບຮັກສາຫນຶ່ງຄັ້ງ, ແລະໃບອະນຸຍາດສໍາລັບການ replica ຄໍາຮ້ອງສະຫມັກຈໍາເປັນຕ້ອງໄດ້ຊື້ສໍາລັບແຕ່ລະຄໍາຮ້ອງສະຫມັກແຍກຕ່າງຫາກ. ຖ້າຫາກວ່າມີຫຼາຍຄໍາຮ້ອງສະຫມັກດັ່ງກ່າວ, ຫຼັງຈາກນັ້ນມັນມີຄ່າໃຊ້ຈ່າຍເປັນ penny pretty ແລະຄ່າໃຊ້ຈ່າຍຂອງໃບອະນຸຍາດສໍາລັບການເກັບຮັກສາ replication ກາຍເປັນການຫຼຸດລົງໃນມະຫາສະຫມຸດໄດ້.

Arguments ຕ້ານການຈໍາລອງການເກັບຂໍ້ມູນ:

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

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

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

ເຮັດດ້ວຍທິດສະດີ, ໃນປັດຈຸບັນປະຕິບັດ

ພວກເຮົາຈະຕັ້ງຄ່າການຈໍາລອງຢູ່ໃນຫ້ອງທົດລອງຂອງພວກເຮົາ. ໃນສະພາບຫ້ອງທົດລອງ, ພວກເຮົາໄດ້ເຮັດຕາມສອງສູນຂໍ້ມູນ (ໃນຄວາມເປັນຈິງ, ສອງ racks ທີ່ຢູ່ໃກ້ຄຽງທີ່ເບິ່ງຄືວ່າຢູ່ໃນອາຄານທີ່ແຕກຕ່າງກັນ). ຂາຕັ້ງປະກອບດ້ວຍສອງລະບົບການເກັບຮັກສາ Engine N2, ເຊິ່ງເຊື່ອມຕໍ່ກັນໂດຍສາຍ optical. ເຊີບເວີທາງດ້ານຮ່າງກາຍທີ່ໃຊ້ Windows Server 2016 ແມ່ນເຊື່ອມຕໍ່ກັບລະບົບການເກັບຮັກສາທັງສອງໂດຍໃຊ້ 10Gb Ethernet. ການຢືນແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ, ແຕ່ນີ້ບໍ່ໄດ້ປ່ຽນແປງໂດຍເນື້ອແທ້ແລ້ວ.

ຕາມ​ແຜນ​ການ​ມັນ​ຄື​ດັ່ງ​ນີ້​:

ຕາມເຫດຜົນ, ການຈໍາລອງໄດ້ຖືກຈັດເປັນດັ່ງຕໍ່ໄປນີ້:

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

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

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

ໃນປັດຈຸບັນ, ລະບົບການເກັບຮັກສາ AERODISK ENGINE ສະຫນັບສະຫນູນການຈໍາລອງສໍາລັບອຸປະກອນຕັນ (LUNs) ຜ່ານ Ethernet protocol (ຫຼາຍກວ່າທອງແດງຫຼື optical). ສໍາລັບໂຄງການທີ່ການຈໍາລອງໂດຍຜ່ານຜ້າ SAN ຜ່ານ Fiber Channel ແມ່ນຕ້ອງການ, ປະຈຸບັນພວກເຮົາກໍາລັງເພີ່ມການແກ້ໄຂທີ່ເຫມາະສົມ, ແຕ່ມັນຍັງບໍ່ພ້ອມ, ດັ່ງນັ້ນໃນກໍລະນີຂອງພວກເຮົາ, ມີພຽງແຕ່ Ethernet ເທົ່ານັ້ນ.

ການຈໍາລອງສາມາດເຮັດວຽກລະຫວ່າງລະບົບການເກັບຮັກສາຊຸດ ENGINE ໃດໆ (N1, N2, N4) ຈາກລະບົບ junior ໄປຫາຜູ້ສູງອາຍຸແລະໃນທາງກັບກັນ.

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

• ການຈໍາລອງ "ຫນຶ່ງຕໍ່ຫນຶ່ງ" ຫຼື "ຫນຶ່ງຫາຫນຶ່ງ", ນັ້ນແມ່ນ, ຮຸ່ນຄລາສສິກທີ່ມີສອງສູນຂໍ້ມູນ, ຕົ້ນຕໍແລະສໍາຮອງຂໍ້ມູນ.
• ການຈໍາລອງແມ່ນ "ຫນຶ່ງຫາຫຼາຍ" ຫຼື "ຫນຶ່ງຫາຫຼາຍ", i.e. ຫນຶ່ງ LUN ສາມາດ replicated ກັບຫຼາຍລະບົບການເກັບຮັກສາໃນເວລາດຽວກັນ
• ເປີດໃຊ້, ປິດໃຊ້ງານ, ແລະ "ກັບຄືນ" ການຈໍາລອງ, ຕາມລໍາດັບ, ເພື່ອເປີດໃຊ້, ປິດການໃຊ້ງານ, ຫຼືປ່ຽນທິດທາງຂອງການຈໍາລອງ
• ການຈໍາລອງແມ່ນສາມາດໃຊ້ໄດ້ສໍາລັບທັງສອງກຸ່ມ RDG (Raid Distributed Group) ແລະ DDP (Dynamic Disk Pool). ຢ່າງໃດກໍຕາມ, LUNs ຂອງສະນຸກເກີ RDG ພຽງແຕ່ສາມາດ replicated ກັບ RDG ອື່ນ. ດຽວກັນກັບ DDP.

ມີຫຼາຍລັກສະນະນ້ອຍໆ, ແຕ່ບໍ່ມີຈຸດພິເສດໃນລາຍຊື່ພວກມັນ; ພວກເຮົາຈະກ່າວເຖິງພວກມັນເມື່ອພວກເຮົາຕັ້ງຄ່າ.

ການ​ຕັ້ງ​ຄ່າ​ການ​ຈໍາ​ລອງ​

ຂະບວນການຕິດຕັ້ງແມ່ນຂ້ອນຂ້າງງ່າຍດາຍແລະປະກອບດ້ວຍສາມຂັ້ນຕອນ.

1. ການຕັ້ງຄ່າເຄືອຂ່າຍ
2. ການ​ຕັ້ງ​ຄ່າ​ການ​ເກັບ​ຮັກ​ສາ​
3. ການຕັ້ງຄ່າກົດລະບຽບ (ການເຊື່ອມຕໍ່) ແລະການສ້າງແຜນທີ່

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

ການຕັ້ງຄ່າຊັບພະຍາກອນເຄືອຂ່າຍ

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

ຫຼັງຈາກນີ້, ພວກເຮົາຈໍາເປັນຕ້ອງສ້າງສະນຸກເກີ (ໃນກໍລະນີຂອງພວກເຮົາ RDG) ແລະ IP virtual ສໍາລັບ replication (VIP). VIP ແມ່ນທີ່ຢູ່ IP ທີ່ເລື່ອນໄດ້ທີ່ຕິດກັບສອງທີ່ຢູ່ "ທາງດ້ານຮ່າງກາຍ" ຂອງຕົວຄວບຄຸມການເກັບຮັກສາ (ພອດທີ່ພວກເຮົາຫາກໍຕັ້ງຄ່າ). ນີ້ຈະເປັນການໂຕ້ຕອບການຈໍາລອງຕົ້ນຕໍ. ນອກນັ້ນທ່ານຍັງສາມາດດໍາເນີນການບໍ່ໄດ້ກັບ VIP, ແຕ່ມີ VLAN, ຖ້າທ່ານຕ້ອງການເຮັດວຽກກັບການຈະລາຈອນ tagged.

ຂະບວນການສ້າງ VIP ສໍາລັບ replica ແມ່ນບໍ່ແຕກຕ່າງກັນຫຼາຍຈາກການສ້າງ VIP ສໍາລັບ I/O (NFS, SMB, iSCSI). ໃນກໍລະນີນີ້, ພວກເຮົາສ້າງ VIP ປົກກະຕິ (ໂດຍບໍ່ມີ VLAN), ແຕ່ໃຫ້ແນ່ໃຈວ່າຈະຊີ້ບອກວ່າມັນແມ່ນສໍາລັບການຈໍາລອງ (ໂດຍບໍ່ມີຕົວຊີ້ນີ້, ພວກເຮົາຈະບໍ່ສາມາດເພີ່ມ VIP ກັບກົດລະບຽບໃນຂັ້ນຕອນຕໍ່ໄປ).

VIP ຈະຕ້ອງຢູ່ໃນເຄືອຂ່າຍຍ່ອຍດຽວກັນກັບພອດ IP ລະຫວ່າງທີ່ມັນລອຍຢູ່.

ພວກເຮົາເຮັດຊ້ໍາການຕັ້ງຄ່າເຫຼົ່ານີ້ຢູ່ໃນລະບົບການເກັບຮັກສາຫ່າງໄກສອກຫຼີກ, ແນ່ນອນ, ມີ IP ທີ່ແຕກຕ່າງກັນ.
VIPs ຈາກລະບົບການເກັບຮັກສາທີ່ແຕກຕ່າງກັນສາມາດຢູ່ໃນ subnets ທີ່ແຕກຕ່າງກັນ, ສິ່ງທີ່ສໍາຄັນແມ່ນວ່າມີເສັ້ນທາງລະຫວ່າງພວກເຂົາ. ໃນກໍລະນີຂອງພວກເຮົາ, ຕົວຢ່າງນີ້ແມ່ນສະແດງໃຫ້ເຫັນຢ່າງແທ້ຈິງ (192.168.3.XX ແລະ 192.168.2.XX)

ນີ້ສໍາເລັດການກະກຽມຂອງພາກສ່ວນເຄືອຂ່າຍ.

ການ​ຕັ້ງ​ຄ່າ​ການ​ເກັບ​ຮັກ​ສາ​

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

ໃນສະນຸກເກີທີ່ສ້າງກ່ອນຫນ້ານີ້ R02, ທ່ານຈໍາເປັນຕ້ອງສ້າງ LUN. ໃຫ້ສ້າງມັນແລະໂທຫາມັນ LUN1.

ພວກເຮົາຍັງຕ້ອງການສ້າງ LUN ດຽວກັນໃນລະບົບການເກັບຮັກສາຫ່າງໄກສອກຫຼີກທີ່ມີຂະຫນາດດຽວກັນ. ພວກເຮົາສ້າງ. ເພື່ອຫຼີກເວັ້ນການສັບສົນ, ໃຫ້ໂທຫາຫ່າງໄກສອກຫຼີກ LUN LUN1R

ຖ້າພວກເຮົາຕ້ອງການເອົາ LUN ທີ່ມີຢູ່ແລ້ວ, ຫຼັງຈາກນັ້ນໃນຂະນະທີ່ຕັ້ງການຈໍາລອງ, ພວກເຮົາຈໍາເປັນຕ້ອງຖອນການຕິດຕັ້ງ LUN ທີ່ມີຜົນຜະລິດນີ້ຈາກເຈົ້າພາບ, ແລະພຽງແຕ່ສ້າງ LUN ຫວ່າງເປົ່າທີ່ມີຂະຫນາດດຽວກັນຢູ່ໃນລະບົບເກັບຮັກສາຫ່າງໄກສອກຫຼີກ.

ການ​ຕັ້ງ​ຄ່າ​ການ​ເກັບ​ຮັກ​ສາ​ສໍາ​ເລັດ​ສົມ​ບູນ​, ພວກ​ເຮົາ​ໄປ​ກັບ​ການ​ສ້າງ​ກົດ​ລະ​ບຽບ​ການ​ຈໍາ​ລອງ​.

ການຕັ້ງຄ່າກົດລະບຽບການຈໍາລອງຫຼືການເຊື່ອມຕໍ່ການຈໍາລອງ

ຫຼັງຈາກການສ້າງ LUNs ໃນລະບົບການເກັບຮັກສາ, ເຊິ່ງຈະເປັນຕົ້ນຕໍໃນປັດຈຸບັນ, ພວກເຮົາກໍານົດກົດລະບຽບການຈໍາລອງ LUN1 ໃນລະບົບການເກັບຮັກສາ 1 ເຖິງ LUN1R ໃນລະບົບການເກັບຮັກສາ 2.

ການຕັ້ງຄ່າແມ່ນເຮັດຢູ່ໃນເມນູ "ການຈໍາລອງໄລຍະໄກ".

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

ໃນພາກສະຫນາມ "ລະບົບຫ່າງໄກສອກຫຼີກ" ພວກເຮົາເພີ່ມລະບົບການເກັບຮັກສາຂອງພວກເຮົາ2. ເພື່ອເພີ່ມ, ທ່ານຈໍາເປັນຕ້ອງໃຊ້ລະບົບການເກັບຮັກສາ IP ການຄຸ້ມຄອງ (MGR) ແລະຊື່ຂອງ LUN ຫ່າງໄກສອກຫຼີກທີ່ພວກເຮົາຈະດໍາເນີນການ replication (ໃນກໍລະນີຂອງພວກເຮົາ, LUN1R). IP ຄວບຄຸມແມ່ນຈໍາເປັນພຽງແຕ່ໃນຂັ້ນຕອນຂອງການເພີ່ມການເຊື່ອມຕໍ່; ການຈະລາຈອນ replication ຈະບໍ່ຖືກສົ່ງຜ່ານພວກມັນ; VIP ທີ່ກໍານົດໄວ້ກ່ອນຫນ້ານີ້ຈະຖືກນໍາໃຊ້ສໍາລັບການນີ້.

ແລ້ວໃນຂັ້ນຕອນນີ້ພວກເຮົາສາມາດເພີ່ມຫຼາຍກວ່າຫນຶ່ງລະບົບຫ່າງໄກສອກຫຼີກສໍາລັບ "ຫນຶ່ງຫາຫຼາຍ" topology: ໃຫ້ຄລິກໃສ່ປຸ່ມ "ເພີ່ມ node", ໃນຮູບຂ້າງລຸ່ມນີ້.

ໃນກໍລະນີຂອງພວກເຮົາ, ມີພຽງແຕ່ຫນຶ່ງລະບົບຫ່າງໄກສອກຫຼີກ, ດັ່ງນັ້ນພວກເຮົາຈໍາກັດຕົວເອງກັບສິ່ງນີ້.

ກົດລະບຽບແມ່ນກຽມພ້ອມ. ກະລຸນາສັງເກດວ່າມັນຖືກເພີ່ມໂດຍອັດຕະໂນມັດໃນຜູ້ເຂົ້າຮ່ວມການຈໍາລອງທັງຫມົດ (ໃນກໍລະນີຂອງພວກເຮົາມີສອງອັນ). ທ່ານ​ສາ​ມາດ​ສ້າງ​ກົດ​ລະ​ບຽບ​ຫຼາຍ​ເທົ່າ​ທີ່​ທ່ານ​ຕ້ອງ​ການ​, ສໍາ​ລັບ​ຈໍາ​ນວນ​ຂອງ LUN ແລະ​ໃນ​ທິດ​ທາງ​ໃດ​ຫນຶ່ງ​. ສໍາລັບຕົວຢ່າງ, ເພື່ອດຸ່ນດ່ຽງການໂຫຼດ, ພວກເຮົາສາມາດ replicate ບາງສ່ວນຂອງ LUNs ຈາກລະບົບການເກັບຮັກສາ 1 ກັບລະບົບການເກັບຮັກສາ 2, ແລະພາກສ່ວນອື່ນໆ, ໃນທາງກົງກັນຂ້າມ, ຈາກລະບົບການເກັບຮັກສາ 2 ກັບລະບົບການເກັບຮັກສາ 1.

ລະ​ບົບ​ການ​ເກັບ​ຮັກ​ສາ 1. ທັນທີຫຼັງຈາກການສ້າງ, synchronization ໄດ້ເລີ່ມຕົ້ນ.

ລະ​ບົບ​ການ​ເກັບ​ຮັກ​ສາ 2. ພວກເຮົາເຫັນກົດລະບຽບດຽວກັນ, ແຕ່ synchronization ໄດ້ສິ້ນສຸດລົງແລ້ວ.

LUN1 ໃນລະບົບການເກັບຮັກສາ 1 ແມ່ນຢູ່ໃນບົດບາດຕົ້ນຕໍ, ນັ້ນແມ່ນ, ມັນມີການເຄື່ອນໄຫວ. LUN1R ໃນລະບົບການເກັບຮັກສາ 2 ແມ່ນຢູ່ໃນບົດບາດຂອງຮອງ, ນັ້ນແມ່ນ, ມັນຢູ່ໃນສະແຕນບາຍໃນກໍລະນີທີ່ລະບົບການເກັບຮັກສາ 1 ລົ້ມເຫລວ.
ໃນປັດຈຸບັນພວກເຮົາສາມາດເຊື່ອມຕໍ່ LUN ຂອງພວກເຮົາກັບເຈົ້າພາບ.

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

ຄວາມແຕກຕ່າງພຽງແຕ່ວ່າພວກເຮົາສ້າງແຜນທີ່ຢູ່ໃນເມນູ "Replication Mapping".

ພວກເຮົາກໍານົດແຜນທີ່ແລະມອບ LUN ໃຫ້ກັບເຈົ້າພາບ. ເຈົ້າພາບໄດ້ເຫັນ LUN.

ພວກເຮົາຈັດຮູບແບບມັນເຂົ້າໄປໃນລະບົບໄຟລ໌ທ້ອງຖິ່ນ.

ນັ້ນແມ່ນ, ການຕິດຕັ້ງສໍາເລັດ. ການທົດສອບຈະມາຕໍ່ໄປ.

ການທົດສອບ

ພວກເຮົາຈະທົດສອບສາມສະຖານະການຕົ້ນຕໍ.

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

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

ທັງສອງລະບົບການເກັບຮັກສາໃນປັດຈຸບັນມີຂໍ້ມູນ "ທີ່ເປັນປະໂຫຍດ", ພວກເຮົາສາມາດເລີ່ມຕົ້ນການທົດສອບໄດ້.

ພຽງແຕ່ໃນກໍລະນີ, ໃຫ້ພວກເຮົາເບິ່ງຜົນລວມ hash ຂອງໄຟລ໌ຫນຶ່ງແລະຂຽນມັນລົງ.

ການປ່ຽນບົດບາດປົກກະຕິ

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

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

ໃນລະບົບການເກັບຮັກສາຕົ້ນຕໍ, ພວກເຮົາປິດການທໍາງານແຜນທີ່ເພື່ອຮັບປະກັນວ່າການບັນທຶກຢຸດ.

ຫຼັງຈາກນັ້ນ, ໃນຫນຶ່ງຂອງລະບົບການເກັບຮັກສາ (ມັນບໍ່ສໍາຄັນ, ໃນຕົ້ນຕໍຫຼືສໍາຮອງຂໍ້ມູນ) ໃນເມນູ "replication Remote", ເລືອກ REPL1 ການເຊື່ອມຕໍ່ຂອງພວກເຮົາແລະໃຫ້ຄລິກໃສ່ "ປ່ຽນບົດບາດ".

ຫຼັງຈາກສອງສາມວິນາທີ, LUN1R (ລະບົບການເກັບຮັກສາສໍາຮອງຂໍ້ມູນ) ກາຍເປັນປະຖົມ.

ພວກເຮົາສ້າງແຜນທີ່ LUN1R ກັບລະບົບການເກັບຮັກສາ 2.

ຫຼັງຈາກນີ້, ໄດ E: ຂອງພວກເຮົາຖືກຕິດກັບເຈົ້າພາບໂດຍອັດຕະໂນມັດ, ພຽງແຕ່ເວລານີ້ "ມາຮອດ" ຈາກ LUN1R.

ພຽງແຕ່ໃນກໍລະນີ, ພວກເຮົາສົມທຽບການລວມ hash.

ຄືກັນ. ການທົດສອບຜ່ານ.

ລົ້ມເຫລວ. ສູນຂໍ້ມູນລົ້ມເຫຼວ

ໃນປັດຈຸບັນ, ລະບົບການເກັບຮັກສາຕົ້ນຕໍຫຼັງຈາກການປ່ຽນເປັນປົກກະຕິແມ່ນລະບົບການເກັບຮັກສາ 2 ແລະ LUN1R, ຕາມລໍາດັບ. ເພື່ອຈຳລອງອຸບັດຕິເຫດ, ພວກເຮົາຈະປິດໄຟໃນຕົວຄວບຄຸມການເກັບຮັກສາທັງສອງ.
ບໍ່ມີການເຂົ້າເຖິງມັນອີກຕໍ່ໄປ.

ໃຫ້ເຮົາເບິ່ງວ່າມີຫຍັງເກີດຂຶ້ນໃນລະບົບການເກັບຮັກສາ 1 (ຕົວສຳຮອງໃນຂະນະນີ້).

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

ປ່ຽນບົດບາດຂອງ LUN1 ເປັນປະຖົມ.

ຂ້ອຍກໍາລັງເຮັດແຜນທີ່ກັບເຈົ້າພາບ.

ໃຫ້ແນ່ໃຈວ່າ drive E ປາກົດຢູ່ໃນໂຮດ.

ພວກເຮົາກວດເບິ່ງ hash.

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

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

ມັນໂຫຼດສໍາລັບສອງສາມນາທີແລະຫຼັງຈາກນັ້ນກັບຄືນສູ່ການບໍລິການຫຼັງຈາກການ synchronization ສັ້ນ, ແຕ່ໃນພາລະບົດບາດຂອງຮອງ.

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

ຄວາມລົ້ມເຫຼວຂອງຊ່ອງທາງການສື່ສານລະຫວ່າງສູນຂໍ້ມູນ

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

ໃນປະຖົມພວກເຮົາເຫັນວ່າບໍ່ມີການພົວພັນກັບມັດທະຍົມ.

ໃນ Secondary ພວກເຮົາເຫັນວ່າບໍ່ມີການພົວພັນກັບປະຖົມ.

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

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

ຫຼັງຈາກເວລາໃດຫນຶ່ງ, synchronization ແມ່ນສໍາເລັດ.

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

ການຄົ້ນພົບ

ພວກເຮົາໄດ້ວິເຄາະທິດສະດີ - ສິ່ງທີ່ຈໍາເປັນແລະເປັນຫຍັງ, ມີຂໍ້ດີແລະຂໍ້ເສຍຢູ່ໃສ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຕັ້ງຄ່າ replication synchronous ລະຫວ່າງສອງລະບົບການເກັບຮັກສາ.

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

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

ກະລຸນາຂຽນຄໍາເຫັນ, ພວກເຮົາຈະດີໃຈທີ່ຈະໄດ້ຮັບຄໍາວິພາກວິຈານແລະຄໍາແນະນໍາພາກປະຕິບັດ.

ຈົນກ່ວາຄັ້ງຕໍ່ໄປ.

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