ກຸ່ມ Elasticsearch 200 TB+

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

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

ຂ້ອຍແມ່ນ Pyotr Zaitsev, ຂ້ອຍເຮັດວຽກເປັນຜູ້ບໍລິຫານລະບົບຢູ່ Odnoklassniki. ກ່ອນນັ້ນ, ຂ້ອຍຍັງເປັນຜູ້ບໍລິຫານ, ເຮັດວຽກກັບ Manticore Search, Sphinx search, Elasticsearch. ບາງທີ, ຖ້າການຄົ້ນຫາອື່ນປາກົດ, ຂ້ອຍກໍ່ອາດຈະເຮັດວຽກກັບມັນຄືກັນ. ຂ້າພະເຈົ້າຍັງເຂົ້າຮ່ວມໃນໂຄງການແຫຼ່ງເປີດຈໍານວນຫນຶ່ງບົນພື້ນຖານຄວາມສະຫມັກໃຈ.

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

ຄວາມຕ້ອງການ

ຄວາມ​ຕ້ອງ​ການ​ຂອງ​ລະ​ບົບ​ໄດ້​ຖືກ​ສ້າງ​ເປັນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

• Greylog ແມ່ນຈະຖືກນໍາໃຊ້ເປັນ frontend. ເນື່ອງຈາກວ່າບໍລິສັດມີປະສົບການໃຊ້ຜະລິດຕະພັນນີ້ແລ້ວ, ນັກຂຽນໂປລແກລມແລະນັກທົດສອບຮູ້ມັນ, ມັນມີຄວາມຄຸ້ນເຄີຍແລະສະດວກຕໍ່ພວກເຂົາ.
• ປະລິມານຂໍ້ມູນ: ໂດຍສະເລ່ຍ 50-80 ພັນຂໍ້ຄວາມຕໍ່ວິນາທີ, ແຕ່ຖ້າບາງສິ່ງບາງຢ່າງແຕກ, ຫຼັງຈາກນັ້ນການຈະລາຈອນບໍ່ຈໍາກັດໂດຍສິ່ງໃດກໍ່ຕາມ, ມັນສາມາດເປັນ 2-3 ລ້ານເສັ້ນຕໍ່ວິນາທີ.
• ໂດຍໄດ້ສົນທະນາກັບລູກຄ້າກ່ຽວກັບຄວາມຕ້ອງການສໍາລັບຄວາມໄວຂອງການປະມວນຜົນຄໍາຖາມຄົ້ນຫາ, ພວກເຮົາຮູ້ວ່າຮູບແບບປົກກະຕິຂອງການນໍາໃຊ້ລະບົບດັ່ງກ່າວແມ່ນນີ້: ປະຊາຊົນກໍາລັງຊອກຫາບັນທຶກຂອງຄໍາຮ້ອງສະຫມັກຂອງເຂົາເຈົ້າສໍາລັບສອງມື້ທີ່ຜ່ານມາແລະບໍ່ຕ້ອງການລໍຖ້າຫຼາຍກ່ວາຫນຶ່ງ. ທີສອງສໍາລັບຜົນໄດ້ຮັບຂອງການສອບຖາມທີ່ມີຮູບແບບ.
• ຜູ້ບໍລິຫານໄດ້ຢືນຢັນວ່າລະບົບສາມາດປັບຂະ ໜາດ ໄດ້ງ່າຍຖ້າ ຈຳ ເປັນ, ໂດຍບໍ່ຕ້ອງໃຫ້ພວກເຂົາເຈາະເລິກໃນວິທີການເຮັດວຽກ.
• ດັ່ງນັ້ນວຽກງານບໍາລຸງຮັກສາພຽງແຕ່ທີ່ລະບົບເຫຼົ່ານີ້ຕ້ອງການເປັນໄລຍະແມ່ນການປ່ຽນຮາດແວບາງຢ່າງ.
• ນອກຈາກນັ້ນ, Odnoklassniki ມີປະເພນີດ້ານວິຊາການທີ່ດີເລີດ: ການບໍລິການໃດໆທີ່ພວກເຮົາເປີດຕົວຕ້ອງລອດຊີວິດຈາກຄວາມລົ້ມເຫຼວຂອງສູນຂໍ້ມູນ (ຢ່າງກະທັນຫັນ, ບໍ່ໄດ້ວາງແຜນແລະຢ່າງແທ້ຈິງໃນເວລາໃດກໍ່ຕາມ).

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

ສະ​ພາບ​ແວດ​ລ້ອມ

ພວກເຮົາເຮັດວຽກຢູ່ໃນສີ່ສູນຂໍ້ມູນ, ໃນຂະນະທີ່ຂໍ້ຂໍ້ມູນ Elasticsearch ສາມາດຕັ້ງຢູ່ໃນສາມເທົ່ານັ້ນ (ສໍາລັບເຫດຜົນທີ່ບໍ່ແມ່ນດ້ານວິຊາການ).

ສີ່ສູນຂໍ້ມູນເຫຼົ່ານີ້ມີປະມານ 18 ພັນແຫຼ່ງບັນທຶກທີ່ແຕກຕ່າງກັນ - ຮາດແວ, ຕູ້ຄອນເທນເນີ, ເຄື່ອງ virtual.

ຄຸນນະສົມບັດທີ່ສໍາຄັນ: ກຸ່ມເລີ່ມຕົ້ນໃນບັນຈຸ podman ບໍ່ແມ່ນຢູ່ໃນເຄື່ອງຈັກທາງດ້ານຮ່າງກາຍ, ແຕ່ຢູ່ໃນ ຜະລິດຕະພັນຄລາວຂອງຕົນເອງ one-cloud. ຕູ້ຄອນເທນເນີແມ່ນຮັບປະກັນ 2 ແກນ, ຄ້າຍຄືກັນກັບ 2.0Ghz v4, ໂດຍມີຄວາມເປັນໄປໄດ້ຂອງການຣີໄຊເຄີນແກນທີ່ເຫຼືອຖ້າພວກມັນບໍ່ເຮັດວຽກ.

ໃນຄໍາສັບຕ່າງໆອື່ນໆ:

Topology

ໃນເບື້ອງຕົ້ນຂ້າພະເຈົ້າໄດ້ເຫັນຮູບແບບທົ່ວໄປຂອງການແກ້ໄຂດັ່ງຕໍ່ໄປນີ້:

• 3-4 VIPs ແມ່ນຢູ່ຫລັງ A-record ຂອງໂດເມນ Greylog, ນີ້ແມ່ນທີ່ຢູ່ທີ່ຈະສົ່ງບັນທຶກ.
• VIP ແຕ່ລະຄົນແມ່ນຕົວດຸ່ນດ່ຽງ LVS.
• ຫຼັງຈາກມັນ, ບັນທຶກໄປຫາຫມໍ້ໄຟ Greylog, ຂໍ້ມູນບາງຢ່າງແມ່ນຢູ່ໃນຮູບແບບ GELF, ບາງຮູບແບບຢູ່ໃນ syslog.
• ຫຼັງຈາກນັ້ນ, ທັງຫມົດນີ້ແມ່ນລາຍລັກອັກສອນໃນ batches ຂະຫນາດໃຫຍ່ກັບຫມໍ້ໄຟຂອງຜູ້ປະສານງານ Elasticsearch.
• ແລະພວກເຂົາ, ໃນທາງກັບກັນ, ສົ່ງຂຽນແລະອ່ານຄໍາຮ້ອງຂໍໄປຫາຂໍ້ຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ.

Terminology

ບາງທີບໍ່ແມ່ນທຸກຄົນເຂົ້າໃຈຄໍາສັບໃນລາຍລະອຽດ, ສະນັ້ນຂ້າພະເຈົ້າຢາກຈະຢູ່ກັບມັນເລັກນ້ອຍ.

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

ຕົ້ນສະບັບ
ມັນ pings ທຸກ nodes ທີ່ມີຢູ່ໃນ cluster, ຮັກສາແຜນທີ່ cluster ທີ່ທັນສະໄຫມແລະແຈກຢາຍມັນລະຫວ່າງ nodes, ຂະບວນການຕາມເຫດຜົນຂອງເຫດການ, ແລະປະຕິບັດປະເພດຕ່າງໆຂອງ cluster wide housekeeping.

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

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

ແກມສີຂີ້ເຖົ່າ
ນີ້ແມ່ນບາງສິ່ງບາງຢ່າງເຊັ່ນ: ການປະສົມປະສານຂອງ Kibana ກັບ Logstash ໃນ stack ELK. Greylog ລວມທັງ UI ແລະທໍ່ການປະມວນຜົນບັນທຶກ. ພາຍໃຕ້ຝາປິດ, Graylog ແລ່ນ Kafka ແລະ Zookeeper, ເຊິ່ງສະຫນອງການເຊື່ອມຕໍ່ກັບ Graylog ເປັນກຸ່ມ. Graylog ສາມາດ cache ບັນທຶກ (Kafka) ໃນກໍລະນີທີ່ Elasticsearch ບໍ່ສາມາດໃຊ້ໄດ້ແລະເຮັດຊ້ໍາຄືນຄໍາຮ້ອງຂໍການອ່ານແລະຂຽນທີ່ບໍ່ສໍາເລັດ, ຈັດກຸ່ມແລະຫມາຍບັນທຶກຕາມກົດລະບຽບທີ່ກໍານົດໄວ້. ເຊັ່ນດຽວກັນກັບ Logstash, Graylog ມີຫນ້າທີ່ແກ້ໄຂແຖວກ່ອນທີ່ຈະຂຽນພວກມັນໃສ່ Elasticsearch.

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

ຕາມສາຍຕາ, ມັນເບິ່ງຄືວ່າ:

ນີ້ແມ່ນພາບໜ້າຈໍຈາກຕົວຢ່າງສະເພາະ. ໃນທີ່ນີ້ພວກເຮົາສ້າງ histogram ໂດຍອີງໃສ່ຄໍາຖາມຄົ້ນຫາແລະສະແດງແຖວທີ່ກ່ຽວຂ້ອງ.

ດັດນີ

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

ໃນແຜນວາດຂ້າງເທິງ, ນີ້ແມ່ນລະດັບຕ່ໍາສຸດ: ຂໍ້ຂໍ້ມູນ Elasticsearch.

ດັດຊະນີແມ່ນຫນ່ວຍງານ virtual ຂະຫນາດໃຫຍ່ທີ່ປະກອບດ້ວຍ Elasticsearch shards. ໃນຕົວຂອງມັນເອງ, ແຕ່ລະ shards ບໍ່ມີຫຍັງຫຼາຍກ່ວາດັດຊະນີ Lucene. ແລະແຕ່ລະດັດຊະນີ Lucene, ໃນທາງກັບກັນ, ປະກອບດ້ວຍຫນຶ່ງຫຼືຫຼາຍສ່ວນ.

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

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

ພວກເຮົາທໍາອິດກໍານົດເວລາເກັບຮັກສາເປັນ 30 ມື້.

ການແຜ່ກະຈາຍຂອງ shards ສາມາດສະແດງເປັນຮູບດັ່ງຕໍ່ໄປນີ້:

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

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

ພືດຫມູນວຽນຂອງດັດຊະນີ, i.e. ການສ້າງດັດສະນີໃຫມ່ແລະລຶບອັນເກົ່າແກ່ທີ່ສຸດ, ພວກເຮົາເຮັດໃຫ້ມັນເທົ່າກັບ 48 ຊົ່ວໂມງ (ອີງຕາມຮູບແບບການນໍາໃຊ້ດັດສະນີ: 48 ຊົ່ວໂມງສຸດທ້າຍແມ່ນຊອກຫາເລື້ອຍໆ).

ໄລຍະການຫມູນວຽນຂອງດັດຊະນີນີ້ແມ່ນເນື່ອງມາຈາກເຫດຜົນຕໍ່ໄປນີ້:

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

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

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

ດັ່ງນັ້ນ, ພວກເຮົາພົບວ່າໂດຍສະເລ່ຍ shard ມີນ້ໍາຫນັກປະມານ 20 gigabytes, ແລະມີ 1 shards ຕໍ່ດັດຊະນີ. ດັ່ງນັ້ນ, ຖ້າພວກເຮົາຫມຸນພວກມັນທຸກໆ 360 ຊົ່ວໂມງ, ພວກເຮົາມີ 48 ຂອງພວກເຂົາ. ແຕ່ລະດັດຊະນີມີຂໍ້ມູນເປັນເວລາ 15 ມື້.

ວົງຈອນການຂຽນແລະການອ່ານຂໍ້ມູນ

ລອງຄິດເບິ່ງວ່າຂໍ້ມູນຖືກບັນທຶກໄວ້ໃນລະບົບນີ້ແນວໃດ.

ໃຫ້ເວົ້າວ່າຄໍາຮ້ອງຂໍບາງຢ່າງມາຮອດຈາກ Graylog ກັບຜູ້ປະສານງານ. ຕົວຢ່າງ, ພວກເຮົາຕ້ອງການດັດສະນີ 2-3 ພັນແຖວ.

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

ແມ່ບົດຕອບວ່າ: "ຂຽນຂໍ້ມູນນີ້ໃສ່ shard ເລກ 71," ຫຼັງຈາກນັ້ນມັນຖືກສົ່ງໄປຫາ node ຂໍ້ມູນທີ່ກ່ຽວຂ້ອງໂດຍກົງ, ບ່ອນທີ່ primary-shard number 71 ຕັ້ງຢູ່.

ຫຼັງຈາກນັ້ນ, ບັນທຶກການເຮັດທຸລະກໍາແມ່ນ replicated ກັບ replica-shard, ເຊິ່ງຕັ້ງຢູ່ໃນສູນຂໍ້ມູນອື່ນ.

ຄໍາຮ້ອງຂໍຄົ້ນຫາມາຮອດຈາກ Graylog ໄປຫາຜູ້ປະສານງານ. ຜູ້ປະສານງານປ່ຽນເສັ້ນທາງຕາມດັດຊະນີ, ໃນຂະນະທີ່ Elasticsearch ແຈກຢາຍການຮ້ອງຂໍລະຫວ່າງ primary-shard ແລະ replica-shard ໂດຍໃຊ້ຫຼັກການຮອບວຽນ.

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

ລະບົບທັງຫມົດນີ້ໂດຍສະເລ່ຍດໍາເນີນການຄໍາຖາມຄົ້ນຫາສໍາລັບ 48 ຊົ່ວໂມງສຸດທ້າຍໃນ 300-400ms, ບໍ່ລວມເອົາຄໍາຖາມເຫຼົ່ານັ້ນທີ່ມີ wildcard ຊັ້ນນໍາ.

ດອກໄມ້ດ້ວຍ Elasticsearch: ການຕິດຕັ້ງ Java

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

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

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

ມັນໄດ້ຫັນອອກວ່າການລວມຕົວຂອງດັດຊະນີ Lucene ເກີດຂື້ນຢູ່ນອກສະໂພກ. ແລະຕູ້ຄອນເທນເນີແມ່ນຂ້ອນຂ້າງເຂັ້ມງວດກ່ຽວກັບຊັບພະຍາກອນທີ່ບໍລິໂພກ. ມີພຽງແຕ່ heap ເທົ່ານັ້ນທີ່ສາມາດເຂົ້າກັບຊັບພະຍາກອນເຫຼົ່ານີ້ (ຄ່າ heap.size ແມ່ນປະມານເທົ່າກັບ RAM), ແລະບາງການດໍາເນີນງານນອກ heap ຂັດຂ້ອງກັບຄວາມຜິດພາດການຈັດສັນຫນ່ວຍຄວາມຈໍາຖ້າຫາກວ່າສໍາລັບເຫດຜົນບາງຢ່າງພວກເຂົາບໍ່ເຫມາະສົມກັບ ~ 500MB ທີ່ຍັງຄົງຢູ່ກ່ອນກໍານົດ.

ການ​ແກ້​ໄຂ​ແມ່ນ​ຂ້ອນ​ຂ້າງ​ເລັກ​ນ້ອຍ​: ຈໍາ​ນວນ RAM ທີ່​ມີ​ສໍາ​ລັບ​ພາ​ຊະ​ນະ​ໄດ້​ເພີ່ມ​ຂຶ້ນ​, ຫຼັງ​ຈາກ​ນັ້ນ​ພວກ​ເຮົາ​ລືມ​ວ່າ​ພວກ​ເຮົາ​ແມ່ນ​ແຕ່​ມີ​ບັນ​ຫາ​ດັ່ງ​ກ່າວ​.

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

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

ໃນບາງກໍລະນີ, ການປະຕິບັດການນີ້ໃຊ້ເວລາຂ້ອນຂ້າງຍາວ, ແລະໃນລະຫວ່າງເວລານີ້ກຸ່ມໄດ້ຈັດການເພື່ອຫມາຍ node ນີ້ອອກແລ້ວ. ບັນຫານີ້ຖືກອະທິບາຍໄດ້ດີ ທີ່ນີ້.

ການ​ແກ້​ໄຂ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​: ພວກ​ເຮົາ​ຈໍາ​ກັດ​ຄວາມ​ສາ​ມາດ​ຂອງ Java ໃນ​ການ​ນໍາ​ໃຊ້​ຈໍາ​ນວນ​ຫຼາຍ​ຂອງ​ຄວາມ​ຈໍາ​ນອກ heap ສໍາ​ລັບ​ການ​ດໍາ​ເນີນ​ງານ​ເຫຼົ່າ​ນີ້​. ພວກເຮົາຈຳກັດມັນໄວ້ຢູ່ທີ່ 16 gigabytes (-XX:MaxDirectMemorySize=16g), ຮັບປະກັນວ່າ GC ທີ່ຊັດເຈນຖືກເອີ້ນເລື້ອຍໆ ແລະປະມວນຜົນໄວຂຶ້ນຫຼາຍ, ດັ່ງນັ້ນຈຶ່ງບໍ່ເຮັດໃຫ້ກຸ່ມດັ່ງກ່າວມີຄວາມໝັ້ນຄົງອີກຕໍ່ໄປ.

ບັນຫາສາມ
ຖ້າທ່ານຄິດວ່າບັນຫາກັບ "nodes ອອກຈາກກຸ່ມໃນເວລາທີ່ບໍ່ຄາດຄິດທີ່ສຸດ" ແມ່ນສິ້ນສຸດລົງ, ທ່ານເຂົ້າໃຈຜິດ.

ເມື່ອພວກເຮົາຕັ້ງຄ່າການເຮັດວຽກກັບດັດສະນີ, ພວກເຮົາເລືອກ mmapfs ຫຼຸດຜ່ອນເວລາຄົ້ນຫາ ໃນ shards ສົດທີ່ມີການແບ່ງສ່ວນທີ່ຍິ່ງໃຫຍ່. ນີ້ແມ່ນຄວາມຜິດທີ່ຂ້ອນຂ້າງ, ເພາະວ່າເມື່ອໃຊ້ mmapfs, ໄຟລ໌ຖືກສ້າງແຜນທີ່ເຂົ້າໄປໃນ RAM, ແລະຫຼັງຈາກນັ້ນພວກເຮົາເຮັດວຽກກັບໄຟລ໌ທີ່ມີແຜນທີ່. ດ້ວຍເຫດນີ້, ມັນປະກົດວ່າເມື່ອ GC ພະຍາຍາມຢຸດກະທູ້ໃນແອັບພລິເຄຊັນ, ພວກເຮົາໄປຫາຈຸດປອດໄພເປັນເວລາດົນ, ແລະໃນທາງກັບມັນ, ແອັບພລິເຄຊັນຢຸດການຕອບສະ ໜອງ ຕໍ່ ຄຳ ຮ້ອງຂໍຂອງອາຈານກ່ຽວກັບວ່າມັນມີຊີວິດຢູ່ບໍ? . ຕາມນັ້ນແລ້ວ, ແມ່ບົດເຊື່ອວ່າ node ບໍ່ມີຢູ່ໃນກຸ່ມອີກຕໍ່ໄປ. ຫຼັງຈາກນີ້, ຫຼັງຈາກ 5-10 ວິນາທີ, ຜູ້ເກັບຂີ້ເຫຍື້ອເຮັດວຽກ, ເສັ້ນປະສາດມາເຖິງຊີວິດ, ເຂົ້າໄປໃນກຸ່ມອີກເທື່ອຫນຶ່ງແລະເລີ່ມຕົ້ນການສ້າງ shards. ມັນທັງຫມົດມີຄວາມຮູ້ສຶກຄືກັບ "ການຜະລິດທີ່ພວກເຮົາສົມຄວນ" ແລະບໍ່ເຫມາະສົມສໍາລັບສິ່ງທີ່ຮ້າຍແຮງ.

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

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

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

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

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

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

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

ນີ້ແມ່ນບ່ອນທີ່ບັນຫາກັບ Java ສິ້ນສຸດລົງແລະບັນຫາແບນວິດໄດ້ເລີ່ມຕົ້ນ.

"ຫມາກໄມ້ປ່າເມັດ" ກັບ Elasticsearch: throughput

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

ອາການທໍາອິດທີ່ພົບ: ໃນລະຫວ່າງ "ການລະເບີດ" ບາງຢ່າງໃນການຜະລິດ, ເມື່ອຈໍານວນບັນທຶກຈໍານວນຫລາຍຖືກສ້າງຂື້ນຢ່າງກະທັນຫັນ, ຄວາມຜິດພາດການດັດສະນີ es_rejected_execution ເລີ່ມກະພິບເລື້ອຍໆໃນ Graylog.

ນີ້ແມ່ນເນື່ອງມາຈາກຄວາມຈິງທີ່ວ່າ thread_pool.write.queue ຢູ່ໃນຂໍ້ຂໍ້ມູນຫນຶ່ງ, ຈົນກ່ວາປັດຈຸບັນ Elasticsearch ສາມາດປະມວນຜົນການຮ້ອງຂໍດັດສະນີແລະອັບໂຫລດຂໍ້ມູນໃສ່ shard ໃນແຜ່ນ, ສາມາດ cache ພຽງແຕ່ 200 ຄໍາຮ້ອງຂໍໂດຍຄ່າເລີ່ມຕົ້ນ. ແລະໃນ ເອກະສານ Elasticsearch ມີການເວົ້າຫນ້ອຍຫຼາຍກ່ຽວກັບພາລາມິເຕີນີ້. ມີພຽງຈຳນວນສູງສຸດຂອງກະທູ້ ແລະຂະໜາດເລີ່ມຕົ້ນເທົ່ານັ້ນທີ່ສະແດງ.

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

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

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

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

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

ແຕ່ນີ້ສາມາດຫລີກລ້ຽງໄດ້ບາງສ່ວນເນື່ອງຈາກຄວາມຈິງທີ່ວ່າໃນ Elasticsearch ຮຸ່ນທີ 6, algorithm ປາກົດຂຶ້ນທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດແຈກຢາຍການສອບຖາມລະຫວ່າງຂໍ້ຂໍ້ມູນທີ່ກ່ຽວຂ້ອງບໍ່ໄດ້ຕາມຫຼັກການຮອບວຽນແບບສຸ່ມ (ກ່ອງບັນຈຸທີ່ເຮັດດັດສະນີແລະຖືເປັນຕົ້ນຕໍ. -shard ສາມາດຄ່ອຍມີເວລາຫຼາຍ, ຈະບໍ່ມີວິທີທີ່ຈະຕອບສະຫນອງຢ່າງໄວວາ), ແຕ່ເພື່ອສົ່ງຕໍ່ຄໍາຮ້ອງຂໍນີ້ໄປຫາ container ຫນ້ອຍທີ່ມີ replica-shard, ເຊິ່ງຈະຕອບສະຫນອງໄວຫຼາຍ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ພວກເຮົາໄດ້ມາຮອດ use_adaptive_replica_selection: true.

ຮູບ​ພາບ​ການ​ອ່ານ​ເລີ່ມ​ຕົ້ນ​ເປັນ​ດັ່ງ​ນີ້​:

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

ສຸດທ້າຍ, ບັນຫາຕົ້ນຕໍແມ່ນການໂຍກຍ້າຍທີ່ບໍ່ເຈັບປວດຂອງສູນຂໍ້ມູນ.

ສິ່ງທີ່ພວກເຮົາຕ້ອງການຈາກ cluster ທັນທີຫຼັງຈາກສູນເສຍການເຊື່ອມຕໍ່ກັບຫນຶ່ງ DC:

• ຖ້າພວກເຮົາມີແມ່ບົດໃນປະຈຸບັນຢູ່ໃນສູນຂໍ້ມູນທີ່ລົ້ມເຫລວ, ຫຼັງຈາກນັ້ນມັນຈະຖືກເລືອກໃຫມ່ແລະຍ້າຍໄປເປັນ node ໃນ DC ອື່ນ.
• ແມ່ບົດຈະລຶບ nodes ທີ່ບໍ່ສາມາດເຂົ້າເຖິງທັງໝົດອອກຈາກກຸ່ມໄດ້ຢ່າງວ່ອງໄວ.
• ໂດຍອີງໃສ່ສິ່ງທີ່ຍັງເຫຼືອ, ລາວຈະເຂົ້າໃຈ: ໃນສູນຂໍ້ມູນທີ່ສູນເສຍທີ່ພວກເຮົາມີແລະ shards ຕົ້ນຕໍດັ່ງກ່າວ, ລາວຈະສົ່ງເສີມ shards replica complementary ໃນສູນຂໍ້ມູນທີ່ຍັງເຫຼືອ, ແລະພວກເຮົາຈະສືບຕໍ່ indexing ຂໍ້ມູນ.
• ດ້ວຍເຫດນີ້, ການຂຽນແລະການອ່ານຂອງກຸ່ມກຸ່ມຈະຄ່ອຍໆລຸດລົງ, ແຕ່ໂດຍທົ່ວໄປແລ້ວທຸກສິ່ງທຸກຢ່າງຈະເຮັດວຽກ, ເຖິງແມ່ນວ່າຈະຊ້າ, ແຕ່ມີຄວາມຫມັ້ນຄົງ.

ດັ່ງທີ່ມັນໄດ້ຫັນອອກ, ພວກເຮົາຕ້ອງການບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

ແລະພວກເຮົາໄດ້ຮັບດັ່ງຕໍ່ໄປນີ້:

ອັນນີ້ເກີດຂຶ້ນໄດ້ແນວໃດ?

ເມື່ອສູນຂໍ້ມູນຫຼຸດລົງ, ນາຍຂອງພວກເຮົາໄດ້ກາຍເປັນຄໍຂວດ.

ເປັນຫຍັງ?

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

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

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

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

ພວກເຮົາໄດ້ວັດແທກ, ແລະກ່ອນທີ່ຈະສະບັບ 6.4.0, ບ່ອນທີ່ການແກ້ໄຂນີ້, ມັນພຽງພໍສໍາລັບພວກເຮົາທີ່ຈະພ້ອມກັນອອກຂໍ້ມູນພຽງແຕ່ 10 ຂໍ້ອອກຈາກ 360 ເພື່ອປິດ cluster ຢ່າງສົມບູນ.

ມັນເບິ່ງຄືແນວນີ້:

ຫຼັງຈາກເວີຊັນ 6.4.0, ບ່ອນທີ່ຂໍ້ບົກພ່ອງທີ່ຂີ້ຮ້າຍນີ້ຖືກແກ້ໄຂ, ຂໍ້ຂໍ້ມູນຢຸດການຂ້າແມ່ແບບ. ແຕ່ນັ້ນບໍ່ໄດ້ເຮັດໃຫ້ລາວ "ສະຫລາດກວ່າ." ຄື: ເມື່ອພວກເຮົາສົ່ງຂໍ້ມູນ 2, 3 ຫຼື 10 (ຕົວເລກໃດໆນອກເຫນືອຈາກຫນຶ່ງ), ຕົ້ນສະບັບໄດ້ຮັບຂໍ້ຄວາມທໍາອິດທີ່ບອກວ່າ node A ໄດ້ອອກໄປ, ແລະພະຍາຍາມບອກ node B, node C ກ່ຽວກັບເລື່ອງນີ້, node D.

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

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

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

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

ດັ່ງນັ້ນ, ການດໍາເນີນງານຂອງການຖອນສູນຂໍ້ມູນໃນມື້ນີ້ໃຊ້ເວລາພວກເຮົາປະມານ 5 ນາທີໃນລະຫວ່າງຊົ່ວໂມງເລັ່ງດ່ວນ. ສໍາລັບ colossus ຂະຫນາດໃຫຍ່ແລະ clumsy ດັ່ງກ່າວ, ນີ້ແມ່ນຜົນໄດ້ຮັບທີ່ດີ pretty.

ດັ່ງນັ້ນ, ພວກເຮົາມາຮອດການຕັດສິນໃຈດັ່ງຕໍ່ໄປນີ້:

• ພວກ​ເຮົາ​ມີ 360 ຂໍ້​ມູນ​ທີ່​ມີ 700 gigabyte disks​.
• 60 ຜູ້ປະສານງານສໍາລັບການກໍານົດເສັ້ນທາງການຈະລາຈອນໂດຍຜ່ານຂໍ້ຂໍ້ມູນດຽວກັນເຫຼົ່ານີ້.
• 40 ແມ່ບົດທີ່ພວກເຮົາໄດ້ປະໄວ້ເປັນປະເພດຂອງມໍລະດົກນັບຕັ້ງແຕ່ສະບັບກ່ອນ 6.4.0 - ເພື່ອຄວາມຢູ່ລອດການຖອນສູນຂໍ້ມູນ, ພວກເຮົາໄດ້ກະກຽມຈິດໃຈທີ່ຈະສູນເສຍເຄື່ອງຈັກຫຼາຍເພື່ອໄດ້ຮັບການຮັບປະກັນວ່າມີກຸ່ມຂອງແມ່ບົດເຖິງແມ່ນວ່າໃນ. ສະຖານະການກໍລະນີທີ່ຮ້າຍແຮງທີ່ສຸດ
• ຄວາມພະຍາຍາມທີ່ຈະສົມທົບການພາລະບົດບາດໃນຫນຶ່ງບັນຈຸແມ່ນໄດ້ພົບກັບຄວາມຈິງທີ່ວ່າໄວຫຼືຫຼັງຈາກນັ້ນ node ຈະທໍາລາຍພາຍໃຕ້ການໂຫຼດ.
• ກຸ່ມທັງຫມົດໃຊ້ heap.size ຂອງ 31 gigabytes: ຄວາມພະຍາຍາມທັງຫມົດເພື່ອຫຼຸດຜ່ອນຂະຫນາດໄດ້ສົ່ງຜົນໃຫ້ບໍ່ວ່າຈະຂ້າບາງ nodes ໃນຄໍາຖາມຄົ້ນຫາຢ່າງຮຸນແຮງທີ່ມີ wildcard ຊັ້ນນໍາຫຼືໄດ້ຮັບ breaker ວົງຈອນໃນ Elasticsearch ຕົວຂອງມັນເອງ.
• ນອກຈາກນັ້ນ, ເພື່ອຮັບປະກັນການປະຕິບັດການຄົ້ນຫາ, ພວກເຮົາໄດ້ພະຍາຍາມຮັກສາຈໍານວນຂອງວັດຖຸໃນກຸ່ມນ້ອຍເທົ່າທີ່ເປັນໄປໄດ້, ເພື່ອປະມວນຜົນເຫດການຫນ້ອຍເທົ່າທີ່ເປັນໄປໄດ້ໃນຄໍຂວດທີ່ພວກເຮົາໄດ້ຮັບໃນແມ່ບົດ.

ສຸດທ້າຍກ່ຽວກັບການຕິດຕາມກວດກາ

ເພື່ອຮັບປະກັນວ່າສິ່ງທັງ ໝົດ ນີ້ເຮັດວຽກຕາມຈຸດປະສົງ, ພວກເຮົາຕິດຕາມສິ່ງຕໍ່ໄປນີ້:

• ແຕ່ລະ node ຂໍ້ມູນລາຍງານຕໍ່ຄລາວຂອງພວກເຮົາວ່າມັນມີຢູ່, ແລະມີ shards ດັ່ງກ່າວແລະດັ່ງກ່າວຢູ່ໃນມັນ. ເມື່ອພວກເຮົາດັບໄຟຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ, ກຸ່ມລາຍງານຫຼັງຈາກ 2-3 ວິນາທີວ່າຢູ່ໃນສູນ A ພວກເຮົາດັບສູນ 2, 3, ແລະ 4 - ນີ້ຫມາຍຄວາມວ່າໃນສູນຂໍ້ມູນອື່ນໆທີ່ພວກເຮົາບໍ່ມີສະຖານະການສາມາດດັບມອດທີ່ມີພຽງແຕ່ຫນຶ່ງ shard. ຊ້າຍ.
• ໂດຍຮູ້ລັກສະນະຂອງພຶດຕິກໍາຂອງແມ່ບົດ, ພວກເຮົາເບິ່ງຢ່າງລະອຽດກ່ຽວກັບຈໍານວນວຽກງານທີ່ຍັງຄ້າງຢູ່. ເນື່ອງຈາກວ່າເຖິງແມ່ນວ່າວຽກງານຫນຶ່ງທີ່ຕິດຢູ່, ຖ້າມັນບໍ່ຫມົດເວລາ, ໃນທາງທິດສະດີໃນສະຖານະການສຸກເສີນບາງຢ່າງສາມາດກາຍເປັນເຫດຜົນ, ສໍາລັບຕົວຢ່າງ, ການສົ່ງເສີມການ replica shard ໃນຂັ້ນຕົ້ນບໍ່ໄດ້ເຮັດວຽກ, ຊຶ່ງເປັນເຫດຜົນທີ່ວ່າດັດສະນີຈະຢຸດເຮັດວຽກ.
• ພວກເຮົາຍັງເບິ່ງຢ່າງໃກ້ຊິດກ່ຽວກັບຄວາມລ່າຊ້າຂອງເຄື່ອງເກັບຂີ້ເຫຍື້ອ, ເພາະວ່າພວກເຮົາມີຄວາມຫຍຸ້ງຍາກອັນໃຫຍ່ຫຼວງໃນເລື່ອງນີ້ໃນລະຫວ່າງການເພີ່ມປະສິດທິພາບ.
• ປະຕິເສດໂດຍກະທູ້ເພື່ອເຂົ້າໃຈລ່ວງຫນ້າວ່າຄໍຂວດຢູ່ໃສ.
• ດີ, ຕົວຊີ້ວັດມາດຕະຖານເຊັ່ນ heap, RAM ແລະ I/O.

ເມື່ອຕິດຕາມກວດກາການກໍ່ສ້າງ, ທ່ານຕ້ອງຄໍານຶງເຖິງລັກສະນະຂອງ Thread Pool ໃນ Elasticsearch. ເອກະສານ Elasticsearch ອະທິບາຍຕົວເລືອກການຕັ້ງຄ່າ ແລະຄ່າເລີ່ມຕົ້ນສໍາລັບການຄົ້ນຫາ ແລະການສ້າງດັດສະນີ, ແຕ່ແມ່ນງຽບຫມົດກ່ຽວກັບ thread_pool.management. ກະທູ້ເຫຼົ່ານີ້, ໂດຍສະເພາະ, ຄໍາຖາມເຊັ່ນ _cat/shards ແລະອັນທີ່ຄ້າຍຄືກັນອື່ນໆ, ເຊິ່ງສະດວກໃນການນໍາໃຊ້ໃນເວລາທີ່ຂຽນການຕິດຕາມ. ຂະຫນາດໃຫຍ່ຂອງກຸ່ມ, ການຮ້ອງຂໍດັ່ງກ່າວຫຼາຍແມ່ນປະຕິບັດຕໍ່ຫົວຫນ່ວຍຂອງເວລາ, ແລະ thread_pool.management ທີ່ໄດ້ກ່າວມາຂ້າງເທິງບໍ່ພຽງແຕ່ບໍ່ໄດ້ນໍາສະເຫນີໃນເອກະສານທາງການ, ແຕ່ຍັງຖືກຈໍາກັດໂດຍຄ່າເລີ່ມຕົ້ນເປັນ 5 ກະທູ້, ເຊິ່ງຖືກກໍາຈັດຢ່າງໄວວາ, ຫຼັງຈາກ. ການຕິດຕາມທີ່ຢຸດເຮັດວຽກຢ່າງຖືກຕ້ອງ.

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

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

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