ການສ້າງການແກ້ໄຂທີ່ທົນທານຕໍ່ຄວາມຜິດພາດໂດຍອີງໃສ່ສະຖາປັດຕະຍະກໍາ Oracle RAC ແລະ AccelStor Shared-Nothing

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

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

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

ຕູ້ເຫຼົ່ານີ້ຕ້ອງມີອຸປະກອນ ແລະຊອບແວທີ່ຈຳເປັນທັງໝົດທີ່ອະນຸຍາດໃຫ້ເຮັດວຽກຂອງຖານຂໍ້ມູນ Oracle ໂດຍບໍ່ຄໍານຶງເຖິງສະຖານະຂອງ “ເພື່ອນບ້ານ”. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ການນໍາໃຊ້ການແກ້ໄຂໄພພິບັດ Cross-Rack, ພວກເຮົາກໍາຈັດຄວາມສ່ຽງຂອງຄວາມລົ້ມເຫຼວ:

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

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

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

ທາງເລືອກທີ່ສັບສົນກວ່າແມ່ນຊອບແວແລະ / ຫຼືການເກັບຮັກສາຮາດແວ "virtualizers" ທີ່ຈະລົບລ້າງບັນຫາຄວາມສອດຄ່ອງແລະການແຊກແຊງຄູ່ມື. ແຕ່ຄວາມສັບສົນຂອງການນໍາໃຊ້ແລະການບໍລິຫານຕໍ່ມາ, ເຊັ່ນດຽວກັນກັບຄ່າໃຊ້ຈ່າຍ indecent ຫຼາຍຂອງການແກ້ໄຂດັ່ງກ່າວ, scares off ຈໍານວນຫຼາຍ.

ການແກ້ໄຂ AccelStor NeoSapphire™ All Flash array ແມ່ນດີເລີດສໍາລັບສະຖານະການເຊັ່ນ: ການຟື້ນຕົວໄພພິບັດ Cross-Rack H710 ໃຊ້ສະຖາປັດຕະຍະກໍາ Shared-Nothing. ຮູບແບບນີ້ແມ່ນລະບົບການເກັບຮັກສາສອງໂຫນດທີ່ໃຊ້ເທກໂນໂລຍີ FlexiRemap® ທີ່ເປັນເຈົ້າຂອງເພື່ອເຮັດວຽກກັບ flash drives. ຂອບໃຈ FlexiRemap® NeoSapphire™ H710 ສາມາດໃຫ້ປະສິດທິພາບສູງສຸດ 600K IOPS@4K ການຂຽນແບບສຸ່ມ ແລະການອ່ານແບບສຸ່ມ 1M+ IOPS@4K, ເຊິ່ງບໍ່ສາມາດບັນລຸໄດ້ໃນເວລາທີ່ໃຊ້ລະບົບການເກັບຂໍ້ມູນແບບຄລາສສິກ RAID.

ແຕ່ລັກສະນະຕົ້ນຕໍຂອງ NeoSapphire™ H710 ແມ່ນການປະຕິບັດສອງຂໍ້ໃນຮູບແບບຂອງກໍລະນີແຍກຕ່າງຫາກ, ແຕ່ລະມີສໍາເນົາຂໍ້ມູນຂອງຕົນເອງ. synchronization ຂອງ nodes ແມ່ນດໍາເນີນໂດຍຜ່ານການໂຕ້ຕອບ InfiniBand ພາຍນອກ. ຂໍຂອບໃຈກັບສະຖາປັດຕະຍະກໍານີ້, ມັນເປັນໄປໄດ້ທີ່ຈະແຈກຢາຍ nodes ໄປຫາສະຖານທີ່ທີ່ແຕກຕ່າງກັນໃນໄລຍະຫ່າງເຖິງ 100m, ດັ່ງນັ້ນຈຶ່ງສະຫນອງການແກ້ໄຂໄພພິບັດ Cross-Rack. ທັງສອງ nodes ເຮັດວຽກ synchronously ຢ່າງສົມບູນ. ຈາກຝ່າຍເຈົ້າພາບ, H710 ເບິ່ງຄືວ່າເປັນລະບົບການເກັບຮັກສາສອງການຄວບຄຸມທົ່ວໄປ. ດັ່ງນັ້ນ, ບໍ່ຈໍາເປັນຕ້ອງປະຕິບັດຊອບແວເພີ່ມເຕີມຫຼືທາງເລືອກຮາດແວຫຼືການຕັ້ງຄ່າທີ່ສັບສົນໂດຍສະເພາະ.

ຖ້າພວກເຮົາສົມທຽບທຸກການແກ້ໄຂໄພພິບັດ Cross-Rack ທີ່ອະທິບາຍຂ້າງເທິງ, ຫຼັງຈາກນັ້ນທາງເລືອກຈາກ AccelStor ໂດດເດັ່ນຈາກສ່ວນທີ່ເຫຼືອ:

AccelStor NeoSapphire™ ແບ່ງປັນສະຖາປັດຕະຍະກຳທີ່ບໍ່ມີສິ່ງໃດ
ລະບົບການເກັບຮັກສາຊອບແວຫຼືຮາດແວ "virtualizer".
ການແກ້ໄຂໂດຍອີງໃສ່ການສໍາເນົາ

Availability

ເຊີບເວີລົ້ມເຫລວ
ບໍ່ມີ Downtime
ບໍ່ມີ Downtime
ບໍ່ມີ Downtime

ປ່ຽນຄວາມລົ້ມເຫຼວ
ບໍ່ມີ Downtime
ບໍ່ມີ Downtime
ບໍ່ມີ Downtime

ລະບົບການເກັບຮັກສາລົ້ມເຫລວ
ບໍ່ມີ Downtime
ບໍ່ມີ Downtime
Downtime

ຄວາມລົ້ມເຫຼວຂອງຕູ້ທັງໝົດ
ບໍ່ມີ Downtime
ບໍ່ມີ Downtime
Downtime

ຄ່າໃຊ້ຈ່າຍແລະຄວາມສັບສົນ

ຄ່າ​ໃຊ້​ຈ່າຍ​ໃນ​ການ​ແກ້​ໄຂ​
ຕ່ຳ*
ປະເພດ
ປະເພດ

ຄວາມ​ສັບ​ສົນ​ໃນ​ການ​ນໍາ​ໃຊ້​
ຕ່ໍາ
ປະເພດ
ປະເພດ

*AccelStor NeoSapphire™ ຍັງເປັນ All Flash array, ເຊິ່ງຕາມຄໍານິຍາມບໍ່ມີລາຄາ “3 kopecks,” ໂດຍສະເພາະເນື່ອງຈາກວ່າມັນມີການສະຫງວນສອງເທົ່າ. ຢ່າງໃດກໍ່ຕາມ, ເມື່ອປຽບທຽບຄ່າໃຊ້ຈ່າຍສຸດທ້າຍຂອງການແກ້ໄຂໂດຍອີງໃສ່ມັນກັບຜູ້ທີ່ຄ້າຍຄືກັນຈາກຜູ້ຂາຍອື່ນໆ, ຄ່າໃຊ້ຈ່າຍສາມາດຖືວ່າຕໍ່າ.

Topology ສໍາລັບການເຊື່ອມຕໍ່ເຄື່ອງແມ່ຂ່າຍຂອງແອັບພລິເຄຊັນແລະທຸກ Flash array nodes ຈະມີລັກສະນະນີ້:

ໃນເວລາວາງແຜນ topology, ມັນຍັງແນະນໍາໃຫ້ເຮັດຊ້ໍາປຸ່ມການຈັດການແລະເຄື່ອງແມ່ຂ່າຍເຊື່ອມຕໍ່ກັນ.

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

ການກະກຽມວຽກງານກ່ຽວກັບອາເລ

ອຸປະກອນແລະຊອບແວທີ່ໃຊ້

ຂໍ້ມູນຈໍາເພາະຂອງເຊີບເວີ ແລະສະວິດ

Components
ລາຍ​ລະ​ອຽດ

ເຊີບເວີ Oracle Database 11g
ສອງ

ລະບົບປະຕິບັດການເຊີຟເວີ
oracle linux

ສະບັບຖານຂໍ້ມູນ Oracle
11g (RAC)

ໂປເຊດເຊີຕໍ່ເຄື່ອງແມ່ຂ່າຍ
ສອງ 16 cores Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz

ຫນ່ວຍຄວາມຈໍາທາງດ້ານຮ່າງກາຍຕໍ່ເຄື່ອງແມ່ຂ່າຍ
128GB

ເຄືອຂ່າຍ FC
FC 16Gb/s ທີ່ມີ multipathing

FC HBA
Emulex Lpe-16002B

ພອດ 1GbE ສາທາລະນະທີ່ອຸທິດຕົນເພື່ອການຈັດການກຸ່ມ
ອະແດັບເຕີອີເທີເນັດ Intel RJ45

ສະຫຼັບ FC 16Gb/s
ຫວຍ 6505

ພອດ 10GbE ສ່ວນຕົວສະເພາະສຳລັບການຊິ້ງຂໍ້ມູນ
Intel X520

AccelStor NeoSapphire™ ຂໍ້ມູນຈໍາເພາະຂອງ Flash Array ທັງໝົດ

Components
ລາຍ​ລະ​ອຽດ

ລະບົບການເກັບຮັກສາ
NeoSapphire™ ຮູບແບບທີ່ມີໃຫ້ສູງ: H710

ສະບັບຮູບພາບ
4.0.1

ຈໍາ​ນວນ​ທັງ​ຫມົດ​ຂອງ​ການ​ຂັບ​ລົດ​
48

ຂະຫນາດໄດ
1.92TB

ປະເພດຂັບລົດ
SSD

FC ເປົ້າໝາຍພອດ
16x 16Gb ພອດ (8 ຕໍ່ node)

ພອດການຄຸ້ມຄອງ
ສາຍອີເທີເນັດ 1GbE ທີ່ເຊື່ອມຕໍ່ຫາແມ່ຂ່າຍຜ່ານສະວິດອີເທີເນັດ

ພອດການເຕັ້ນຂອງຫົວໃຈ
ສາຍອີເທີເນັດ 1GbE ທີ່ເຊື່ອມຕໍ່ລະຫວ່າງສອງບ່ອນເກັບຂໍ້ມູນ

ພອດ synchronization ຂໍ້ມູນ
ສາຍ InfiniBand 56Gb/s

ກ່ອນທີ່ທ່ານຈະສາມາດໃຊ້ array, ທ່ານຕ້ອງເລີ່ມຕົ້ນມັນກ່ອນ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ທີ່ຢູ່ຄວບຄຸມຂອງທັງສອງ nodes ແມ່ນຄືກັນ (192.168.1.1). ທ່ານຈໍາເປັນຕ້ອງເຊື່ອມຕໍ່ກັບພວກເຂົາເທື່ອລະອັນແລະກໍານົດທີ່ຢູ່ການຈັດການໃຫມ່ (ທີ່ແຕກຕ່າງກັນແລ້ວ) ແລະຕັ້ງຄ່າ synchronization ເວລາ, ຫຼັງຈາກນັ້ນ Ports Management ສາມາດເຊື່ອມຕໍ່ກັບເຄືອຂ່າຍດຽວ. ຫຼັງຈາກນັ້ນ, nodes ໄດ້ຖືກລວມເຂົ້າເປັນຄູ່ HA ໂດຍການມອບຫມາຍ subnets ສໍາລັບການເຊື່ອມຕໍ່ Interlink.

ຫຼັງຈາກການເລີ່ມຕົ້ນສໍາເລັດ, ທ່ານສາມາດຈັດການ array ຈາກ node ໃດ.

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

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

ທົດສອບການຕັ້ງຄ່າ

ຊື່ປະລິມານການເກັບຮັກສາ
ຂະ ໜາດ ບໍລິມາດ

ຂໍ້ມູນ 01
200GB

ຂໍ້ມູນ 02
200GB

ຂໍ້ມູນ 03
200GB

ຂໍ້ມູນ 04
200GB

ຂໍ້ມູນ 05
200GB

ຂໍ້ມູນ 06
200GB

ຂໍ້ມູນ 07
200GB

ຂໍ້ມູນ 08
200GB

ຂໍ້ມູນ 09
200GB

ຂໍ້ມູນ 10
200GB

ຕາຂ່າຍໄຟຟ້າ 01
1GB

ຕາຂ່າຍໄຟຟ້າ 02
1GB

ຕາຂ່າຍໄຟຟ້າ 03
1GB

ຕາຂ່າຍໄຟຟ້າ 04
1GB

ຕາຂ່າຍໄຟຟ້າ 05
1GB

ຕາຂ່າຍໄຟຟ້າ 06
1GB

ເຮັດຄືນ01
100GB

ເຮັດຄືນ02
100GB

ເຮັດຄືນ03
100GB

ເຮັດຄືນ04
100GB

ເຮັດຄືນ05
100GB

ເຮັດຄືນ06
100GB

ເຮັດຄືນ07
100GB

ເຮັດຄືນ08
100GB

ເຮັດຄືນ09
100GB

ເຮັດຄືນ10
100GB

ຄໍາອະທິບາຍບາງຢ່າງກ່ຽວກັບຮູບແບບການເຮັດວຽກຂອງ array ແລະຂະບວນການທີ່ເກີດຂື້ນໃນສະຖານະການສຸກເສີນ

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

• ກຳນົດເວລາ reboot ຂອງໜຶ່ງໃນ nodes
• ອຸປະຕິເຫດຢູ່ໃນຫນຶ່ງຂອງ nodes ເນື່ອງຈາກການປິດຢ່າງກະທັນຫັນ (ການສະຫນອງພະລັງງານ, overheating, ແລະອື່ນໆ).
• ສູນເສຍການເຊື່ອມຕໍ່ InfiniBand ກັບບໍ່ສາມາດ synchronize
• ເກີດຂັດຂ້ອງຢູ່ໃນໜຶ່ງໃນໂຫນດອັນເນື່ອງມາຈາກຂໍ້ມູນເສຍຫາຍ. ໃນທີ່ນີ້ທ່ານຈະຕ້ອງສ້າງກຸ່ມ HA ໃຫມ່ແລະສໍາເລັດການ synchronization ຂອງຊຸດຂໍ້ມູນ.

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

ຖ້າການເຊື່ອມຕໍ່ຜ່ານການເຊື່ອມຕໍ່ອີເທີເນັດຖືກສູນເສຍ, Heartbeat ຈະປ່ຽນເປັນ InfiniBand ຊົ່ວຄາວແລະກັບຄືນມາພາຍໃນ 10 ວິນາທີເມື່ອມັນຖືກຟື້ນຟູ.

ການຕັ້ງຄ່າເຈົ້າພາບ

ເພື່ອຮັບປະກັນຄວາມທົນທານຄວາມຜິດແລະປັບປຸງການປະຕິບັດ, ທ່ານຕ້ອງເປີດໃຊ້ການຮອງຮັບ MPIO ສໍາລັບ array. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງເພີ່ມເສັ້ນໃສ່ໄຟລ໌ /etc/multipath.conf, ແລະຫຼັງຈາກນັ້ນ restart ການບໍລິການ multipath.

ຂໍ້ຄວາມທີ່ເຊື່ອງໄວ້ອຸປະກອນ {
ອຸປະກອນ {
ຜູ້ຂາຍ "AStor"
path_grouping_policy "group_by_prio"
path_selector "ຄວາມຍາວແຖວ 0"
path_checker "tur"
ຄຸນ​ນະ​ສົມ​ບັດ "0​"
hardware_handler "0"
prio "const"
ລົ້ມເຫລວໃນທັນທີ
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names ແມ່ນແລ້ວ
detect_prio ແມ່ນແລ້ວ
rr_min_io_rq 1
no_path_retry 0
}
}

ຕໍ່ໄປ, ເພື່ອໃຫ້ ASM ເຮັດວຽກກັບ MPIO ຜ່ານ ASMLib, ທ່ານຈໍາເປັນຕ້ອງປ່ຽນໄຟລ໌ /etc/sysconfig/oracleasm ແລະຫຼັງຈາກນັ້ນດໍາເນີນການ /etc/init.d/oracleasm scandisks

ຂໍ້ຄວາມທີ່ເຊື່ອງໄວ້

# ORACLEASM_SCANORDER: ຈັບຄູ່ຮູບແບບເພື່ອສັ່ງການສະແກນແຜ່ນ
ORACLEASM_SCANORDER="dm"

# ORACLEASM_SCANEXCLUDE: ການຈັບຄູ່ຮູບແບບເພື່ອຍົກເວັ້ນແຜ່ນຈາກການສະແກນ
ORACLEASM_SCANEXCLUDE="sd"

Примечание

ຖ້າທ່ານບໍ່ຕ້ອງການໃຊ້ ASMLib, ທ່ານສາມາດນໍາໃຊ້ກົດລະບຽບ UDEV, ເຊິ່ງເປັນພື້ນຖານສໍາລັບ ASMLib.

ໂດຍເລີ່ມຕົ້ນດ້ວຍເວີຊັ່ນ 12.1.0.2 ຂອງ Oracle Database, ທາງເລືອກແມ່ນມີໃຫ້ສຳລັບການຕິດຕັ້ງເປັນສ່ວນໜຶ່ງຂອງຊອບແວ ASMFD.

ມັນເປັນສິ່ງ ຈຳ ເປັນເພື່ອຮັບປະກັນວ່າແຜ່ນທີ່ສ້າງຂື້ນສໍາລັບ Oracle ASM ແມ່ນສອດຄ່ອງກັບຂະ ໜາດ ບລັອກທີ່ array ເຮັດວຽກທາງດ້ານຮ່າງກາຍດ້ວຍ (4K). ຖ້າບໍ່ດັ່ງນັ້ນ, ບັນຫາການປະຕິບັດອາດຈະເກີດຂື້ນ. ດັ່ງນັ້ນ, ມັນຈໍາເປັນຕ້ອງສ້າງປະລິມານທີ່ມີຕົວກໍານົດທີ່ເຫມາະສົມ:

parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check optimal 1

ການແຈກຢາຍຖານຂໍ້ມູນໃນທົ່ວປະລິມານທີ່ສ້າງຂຶ້ນສໍາລັບການຕັ້ງຄ່າການທົດສອບຂອງພວກເຮົາ

ຊື່ປະລິມານການເກັບຮັກສາ
ຂະ ໜາດ ບໍລິມາດ
ແຜນທີ່ປະລິມານຂອງ LUNs
ລາຍລະອຽດອຸປະກອນປະລິມານ ASM
ຂະໜາດຫົວໜ່ວຍການຈັດສັນ

ຂໍ້ມູນ 01
200GB
ສ້າງແຜນທີ່ປະລິມານການເກັບຮັກສາທັງໝົດໃຫ້ກັບລະບົບການເກັບຂໍ້ມູນທຸກພອດຂໍ້ມູນ
ການຊໍ້າຊ້ອນ: ປົກກະຕິ
ຊື່:DGDATA
ຈຸດ​ປະ​ສົງ​: ໄຟລ​໌​ຂໍ້​ມູນ​

4MB

ຂໍ້ມູນ 02
200GB

ຂໍ້ມູນ 03
200GB

ຂໍ້ມູນ 04
200GB

ຂໍ້ມູນ 05
200GB

ຂໍ້ມູນ 06
200GB

ຂໍ້ມູນ 07
200GB

ຂໍ້ມູນ 08
200GB

ຂໍ້ມູນ 09
200GB

ຂໍ້ມູນ 10
200GB

ຕາຂ່າຍໄຟຟ້າ 01
1GB
ການຊໍ້າຊ້ອນ: ປົກກະຕິ
ຊື່: DGGRID1
ຈຸດປະສົງ: ຕາໜ່າງ: CRS ແລະການລົງຄະແນນສຽງ

4MB

ຕາຂ່າຍໄຟຟ້າ 02
1GB

ຕາຂ່າຍໄຟຟ້າ 03
1GB

ຕາຂ່າຍໄຟຟ້າ 04
1GB
ການຊໍ້າຊ້ອນ: ປົກກະຕິ
ຊື່: DGGRID2
ຈຸດປະສົງ: ຕາໜ່າງ: CRS ແລະການລົງຄະແນນສຽງ

4MB

ຕາຂ່າຍໄຟຟ້າ 05
1GB

ຕາຂ່າຍໄຟຟ້າ 06
1GB

ເຮັດຄືນ01
100GB
ການຊໍ້າຊ້ອນ: ປົກກະຕິ
ຊື່: DGREDO1
ຈຸດ​ປະ​ສົງ​: ເຮັດ​ຄືນ​ບັນ​ທຶກ​ຂອງ​ກະ​ທູ້ 1​

4MB

ເຮັດຄືນ02
100GB

ເຮັດຄືນ03
100GB

ເຮັດຄືນ04
100GB

ເຮັດຄືນ05
100GB

ເຮັດຄືນ06
100GB
ການຊໍ້າຊ້ອນ: ປົກກະຕິ
ຊື່: DGREDO2
ຈຸດ​ປະ​ສົງ​: ເຮັດ​ຄືນ​ບັນ​ທຶກ​ຂອງ​ກະ​ທູ້ 2​

4MB

ເຮັດຄືນ07
100GB

ເຮັດຄືນ08
100GB

ເຮັດຄືນ09
100GB

ເຮັດຄືນ10
100GB

ການຕັ້ງຄ່າຖານຂໍ້ມູນ

• ຂະຫນາດຕັນ = 8K
• ພື້ນທີ່ແລກປ່ຽນ = 16GB
• ປິດການນຳໃຊ້ AMM (ການຈັດການຄວາມຈຳອັດຕະໂນມັດ)
• ປິດການໃຊ້ງານຫນ້າຂະຫນາດໃຫຍ່ທີ່ໂປ່ງໃສ

ການຕັ້ງຄ່າອື່ນໆ

# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ kernel.shmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # ຢ່າຕັ້ງອັນນີ້ຖ້າທ່ານໃຊ້ Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000

# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ grid hard nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ ຕາຂ່າຍໄຟຟ້າ 10240
✓ ຕາຂ່າຍໄຟຟ້າແຂງ 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ oracle soft stack 10240
✓ oracle hard stack 32768
✓ memlock ອ່ອນ 120795954
✓ ຍາກ memlock 120795954

sqlplus “/ as sysdba”
ປ່ຽນແປງລະບົບຊຸດຂະບວນການ=2000 ຂອບເຂດ=spfile;
ປ່ຽນແປງລະບົບການຕັ້ງຄ່າ open_cursors=2000 ຂອບເຂດ=spfile;
alter system set session_cached_cursors=300 ຂອບເຂດ=spfile;
ປັບລະບົບການຕັ້ງຄ່າ db_files=8192 ຂອບເຂດ=spfile;

ການທົດສອບຄວາມລົ້ມເຫຼວ

ສໍາລັບຈຸດປະສົງການສາທິດ, HammerDB ໄດ້ຖືກນໍາໃຊ້ເພື່ອເຮັດຕາມການໂຫຼດ OLTP. ການຕັ້ງຄ່າ HammerDB:

ຈໍານວນສາງ
256

ທຸລະກໍາທັງຫມົດຕໍ່ຜູ້ໃຊ້
1000000000000

ຜູ້ໃຊ້ສະເໝືອນ
256

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

ການທົດສອບຄວາມລົ້ມເຫຼວຂອງຫນຶ່ງໃນ nodes

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

ການທົດສອບຄວາມລົ້ມເຫຼວຂອງຕູ້ກັບອຸປະກອນທັງຫມົດ

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

ຖ້າມີຄວາມຕ້ອງການທີ່ຈະປະຕິບັດການແກ້ໄຂໄພພິບັດ Cross-Rack ທີ່ທົນທານຕໍ່ຄວາມຜິດສໍາລັບ Oracle ດ້ວຍຄ່າໃຊ້ຈ່າຍທີ່ສົມເຫດສົມຜົນແລະມີຄວາມພະຍາຍາມໃນການນໍາໃຊ້ / ການບໍລິຫານພຽງເລັກນ້ອຍ, ຫຼັງຈາກນັ້ນ Oracle RAC ແລະສະຖາປັດຕະຍະກໍາເຮັດວຽກຮ່ວມກັນ. AccelStor ແບ່ງປັນ-ບໍ່ມີຫຍັງ ຈະເປັນຫນຶ່ງໃນທາງເລືອກທີ່ດີທີ່ສຸດ. ແທນທີ່ຈະເປັນ Oracle RAC, ສາມາດມີຊອບແວອື່ນໆທີ່ສະຫນອງກຸ່ມ, DBMS ດຽວກັນຫຼືລະບົບ virtualization, ສໍາລັບການຍົກຕົວຢ່າງ. ຫຼັກການຂອງການກໍ່ສ້າງການແກ້ໄຂຈະຍັງຄົງຢູ່ຄືກັນ. ແລະເສັ້ນທາງລຸ່ມແມ່ນສູນສໍາລັບ RTO ແລະ RPO.

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