ເມຄທີ່ທົນທານຕໍ່ໄພພິບັດ: ມັນເຮັດວຽກແນວໃດ

Hey Habr!

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

ລະບົບເກັບຮັກສາຟັງຄລາວທີ່ທົນທານຕໍ່ໄພພິບັດຢູ່ໃນເວັບໄຊທ໌ OST.

ມີຫຍັງຢູ່ພາຍໃນ

ພາຍໃຕ້ຝາປິດ, ກຸ່ມມີເຊີບເວີ Cisco UCS ທີ່ມີ VMware ESXi hypervisor, ສອງລະບົບການເກັບຮັກສາ INFINIDAT InfiniBox F2240, ອຸປະກອນເຄືອຂ່າຍ Cisco Nexus, ເຊັ່ນດຽວກັນກັບສະຫຼັບ Brocade SAN. ກຸ່ມໄດ້ຖືກແບ່ງອອກເປັນສອງສະຖານທີ່ - OST ແລະ NORD, i.e. ແຕ່ລະສູນຂໍ້ມູນມີອຸປະກອນທີ່ຄືກັນ. ໃນຄວາມເປັນຈິງ, ນີ້ແມ່ນສິ່ງທີ່ເຮັດໃຫ້ມັນທົນທານຕໍ່ໄພພິບັດ.

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

ສອງສາມຄໍາກ່ຽວກັບລະບົບການເກັບຮັກສາ. ພວກເຮົາສ້າງຄລາວປ້ອງກັນໄພພິບັດໃນ NetApp ລຸ້ນທຳອິດ. ນີ້ພວກເຮົາເລືອກ INFINIDAT, ແລະນີ້ແມ່ນເຫດຜົນ:

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

ນີ້ແມ່ນບາງຮູບຈາກການ unpacking:

ມັນເຮັດວຽກແນວໃດ

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

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

ການອອກແບບກຸ່ມຖືກອອກແບບເພື່ອໃຫ້ເຈົ້າພາບ ESXi ທີ່ມີເຄື່ອງ virtual ຂອງລູກຄ້າສາມາດເຂົ້າເຖິງລະບົບການເກັບຮັກສາສອງອັນ. ຖ້າລະບົບການເກັບຮັກສາຢູ່ໃນເວັບໄຊທ໌ OST ລົ້ມເຫລວ, ເຄື່ອງຈັກ virtual ຈະສືບຕໍ່ເຮັດວຽກ: ເຈົ້າພາບທີ່ພວກເຂົາກໍາລັງແລ່ນຈະເຂົ້າເຖິງລະບົບການເກັບຮັກສາໃນ NORD ສໍາລັບຂໍ້ມູນ.

ນີ້ແມ່ນສິ່ງທີ່ແຜນວາດການເຊື່ອມຕໍ່ໃນກຸ່ມເບິ່ງຄື.

ນີ້ແມ່ນເປັນໄປໄດ້ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າ Inter-Switch Link ໄດ້ຖືກຕັ້ງຄ່າລະຫວ່າງ fabrics SAN ຂອງສອງສະຖານທີ່: ສະຫຼັບ Fabric A OST SAN ແມ່ນເຊື່ອມຕໍ່ກັບສະຫຼັບ Fabric A NORD SAN, ແລະຄ້າຍຄືກັນກັບສະຫຼັບ Fabric B SAN.

ດີ, ເພື່ອໃຫ້ຄວາມຊັບຊ້ອນທັງຫມົດເຫຼົ່ານີ້ຂອງໂຮງງານ SAN ມີຄວາມຫມາຍ, ການຈໍາລອງແບບ Active-Active ໄດ້ຖືກຕັ້ງຄ່າລະຫວ່າງສອງລະບົບການເກັບຮັກສາ: ຂໍ້ມູນແມ່ນເກືອບພ້ອມໆກັນກັບລະບົບການເກັບຮັກສາທ້ອງຖິ່ນແລະຫ່າງໄກສອກຫຼີກ, RPO = 0. ມັນປະກົດວ່າຂໍ້ມູນຕົ້ນສະບັບຖືກເກັບໄວ້ໃນລະບົບການເກັບຮັກສາຫນຶ່ງ, ແລະການຈໍາລອງຂອງມັນຖືກເກັບໄວ້ໃນອີກອັນຫນຶ່ງ. ຂໍ້ມູນຖືກຈໍາລອງໃນລະດັບຂອງປະລິມານການເກັບຮັກສາ, ແລະຂໍ້ມູນ VM (ແຜ່ນຂອງມັນ, ໄຟລ໌ການຕັ້ງຄ່າ, ໄຟລ໌ swap, ແລະອື່ນໆ) ຖືກເກັບໄວ້ໃນພວກມັນ.

ເຈົ້າພາບ ESXi ເຫັນປະລິມານຕົ້ນຕໍແລະການຈໍາລອງຂອງມັນເປັນອຸປະກອນແຜ່ນດຽວ (ອຸປະກອນເກັບຮັກສາ). ມີ 24 ເສັ້ນທາງຈາກເຈົ້າພາບ ESXi ໄປຫາແຕ່ລະອຸປະກອນດິສກ໌:

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

ຮູບແບບຂອງກຸ່ມປ້ອງກັນໄພພິບັດ.

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

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

ຈະເກີດຫຍັງຂຶ້ນກັບເຄື່ອງ virtual ຂອງລູກຄ້າຖ້າ ...

Replication Link ລົ້ມເຫລວ. ການຈໍາລອງລະຫວ່າງລະບົບການເກັບຮັກສາຂອງສອງສະຖານທີ່ຢຸດ.
ESXi ຈະເຮັດວຽກກັບອຸປະກອນແຜ່ນທ້ອງຖິ່ນເທົ່ານັ້ນ (ຜ່ານເສັ້ນທາງທີ່ດີທີ່ສຸດ).
ເຄື່ອງຈັກ virtual ສືບຕໍ່ເຮັດວຽກ.

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

ເຄື່ອງຈັກ virtual ເຮັດວຽກເປັນປົກກະຕິ.

ສະວິດ SAN ລົ້ມເຫລວໃນຫນຶ່ງໃນເວັບໄຊທ໌. ເຈົ້າພາບ ESXi ສູນເສຍບາງເສັ້ນທາງໄປສູ່ລະບົບການເກັບຮັກສາ. ໃນກໍລະນີນີ້, ເຈົ້າພາບຢູ່ໃນສະຖານທີ່ທີ່ສະຫວິດບໍ່ສໍາເລັດຈະເຮັດວຽກຜ່ານຫນຶ່ງຂອງ HBA ຂອງພວກເຂົາເທົ່ານັ້ນ.

ເຄື່ອງຈັກ virtual ສືບຕໍ່ເຮັດວຽກຕາມປົກກະຕິ.

ສະວິດ SAN ທັງໝົດຢູ່ໃນເວັບໄຊທ໌ໜຶ່ງລົ້ມເຫລວ. ໃຫ້ເວົ້າວ່າໄພພິບັດດັ່ງກ່າວເກີດຂຶ້ນຢູ່ໃນເວັບໄຊທ໌ OST. ໃນກໍລະນີນີ້, ເຈົ້າພາບ ESXi ຢູ່ໃນເວັບໄຊທ໌ນີ້ຈະສູນເສຍເສັ້ນທາງທັງຫມົດໄປຫາອຸປະກອນແຜ່ນຂອງພວກເຂົາ. ກົນໄກມາດຕະຖານ VMware vSphere HA ເຂົ້າມາຫຼິ້ນ: ມັນຈະປິດເປີດເຄື່ອງ virtual ທັງໝົດຂອງ OST site ໃນ NORD ພາຍໃນເວລາສູງສຸດ 140 ວິນາທີ.

ເຄື່ອງຈັກສະເໝືອນທີ່ແລ່ນຢູ່ໃນເວັບໂຮສຂອງ NORD ແມ່ນເຮັດວຽກຕາມປົກກະຕິ.

ເຈົ້າພາບ ESXi ລົ້ມເຫລວຢູ່ໃນເວັບໄຊທ໌ຫນຶ່ງ. ທີ່ນີ້ກົນໄກ vSphere HA ເຮັດວຽກອີກເທື່ອຫນຶ່ງ: ເຄື່ອງຈັກ virtual ຈາກໂຮດທີ່ລົ້ມເຫລວໄດ້ຖືກເລີ່ມຕົ້ນໃຫມ່ໃນໂຮດອື່ນ - ຢູ່ໃນເວັບໄຊທ໌ດຽວກັນຫຼືທາງໄກ. ເວລາປິດເປີດເຄື່ອງສະເໝືອນຈິງແມ່ນສູງສຸດ 1 ນາທີ.

ຖ້າໂຮດ ESXi ທັງຫມົດຢູ່ໃນເວັບໄຊທ໌ OST ລົ້ມເຫລວ, ບໍ່ມີທາງເລືອກ: VMs ຖືກເລີ່ມຕົ້ນໃຫມ່ໃນອັນອື່ນ. ເວລາຣີສະຕາດແມ່ນຄືກັນ.

ລະບົບການເກັບຮັກສາລົ້ມເຫລວຢູ່ບ່ອນດຽວ. ໃຫ້ເວົ້າວ່າລະບົບການເກັບຮັກສາລົ້ມເຫລວຢູ່ໃນເວັບໄຊທ໌ OST. ຫຼັງຈາກນັ້ນ, ເຈົ້າພາບ ESXi ຂອງເວັບໄຊທ໌ OST ສະຫຼັບກັບການເຮັດວຽກກັບ replicas ການເກັບຮັກສາໃນ NORD. ຫຼັງຈາກລະບົບການເກັບຮັກສາທີ່ລົ້ມເຫລວກັບຄືນສູ່ການບໍລິການ, ການຈໍາລອງແບບບັງຄັບຈະເກີດຂຶ້ນແລະເຈົ້າພາບ ESXi OST ອີກເທື່ອຫນຶ່ງຈະເລີ່ມເຂົ້າເຖິງລະບົບການເກັບຮັກສາທ້ອງຖິ່ນ.

ເຄື່ອງຈັກ virtual ໄດ້ເຮັດວຽກເປັນປົກກະຕິຕະຫຼອດເວລານີ້.

ຫນຶ່ງໃນສະຖານທີ່ລົ້ມເຫລວ. ໃນກໍລະນີນີ້, ເຄື່ອງຈັກ virtual ທັງຫມົດຈະຖືກເລີ່ມຕົ້ນໃຫມ່ໃນເວັບໄຊທ໌ສໍາຮອງໂດຍຜ່ານກົນໄກ vSphere HA. ເວລາຣີສະຕາດ VM ແມ່ນ 140 ວິນາທີ. ໃນກໍລະນີນີ້, ການຕັ້ງຄ່າເຄືອຂ່າຍທັງຫມົດຂອງເຄື່ອງ virtual ຈະຖືກບັນທຶກໄວ້, ແລະມັນຍັງຄົງສາມາດເຂົ້າເຖິງລູກຄ້າຜ່ານເຄືອຂ່າຍ.

ເພື່ອຮັບປະກັນວ່າການປິດເປີດເຄື່ອງຄືນໃໝ່ຢູ່ບ່ອນສຳຮອງນັ້ນດຳເນີນໄປຢ່າງຄ່ອງແຄ້ວ, ແຕ່ລະບ່ອນແມ່ນເຕັມເຄິ່ງໜຶ່ງເທົ່ານັ້ນ. ເຄິ່ງທີ່ສອງແມ່ນສະຫງວນໄວ້ໃນກໍລະນີທີ່ເຄື່ອງຈັກ virtual ທັງຫມົດຍ້າຍອອກຈາກສະຖານທີ່ທີສອງ, ເສຍຫາຍ.

ຄລາວທີ່ທົນທານຕໍ່ໄພພິບັດໂດຍອີງໃສ່ສູນຂໍ້ມູນສອງແຫ່ງປົກປ້ອງຄວາມລົ້ມເຫລວດັ່ງກ່າວ.

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

ແຫຼ່ງຂໍ້ມູນ:

1. www.infinidat.com/sites/default/files/resource-pdfs/DS-INFBOX-190331-US_0.pdf
2. support.infinidat.com/hc/en-us/articles/207057109-InfiniBox-best-practices-guides

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