ການປັບປຸງຈຸດກວດກາຈາກ R77.30 ເປັນ 80.20

ໃນລະດູໃບໄມ້ປົ່ງຂອງປີ 2019, Check Point ໄດ້ຢຸດການຮອງຮັບເວີຊັນ R77.XX, ແລະມັນຈໍາເປັນຕ້ອງໄດ້ອັບເດດ. ຫຼາຍຄົນໄດ້ເວົ້າແລ້ວກ່ຽວກັບຄວາມແຕກຕ່າງລະຫວ່າງລຸ້ນ, ຂໍ້ດີແລະຂໍ້ເສຍຂອງການປ່ຽນເປັນ R80. ໃຫ້ພວກເຮົາເວົ້າກັນດີກວ່າກ່ຽວກັບວິທີການອັບເດດ Check Point virtual appliances (CloudGuard ສໍາລັບ VMware ESXi, Hyper-V, KVM Gateway NGTP) ແລະສິ່ງທີ່ອາດຈະຜິດພາດ.

ດັ່ງນັ້ນ, ພວກເຮົາມີວິສະວະກອນ CCSE 2 ຄົນ, ຫຼາຍກວ່າອາຍແກັສ Check Point R77.30 virtual clusters, ຟັງຫຼາຍ, ສອງສາມ hotfixes ແລະທະເລທັງຫມົດຂອງແມງໄມ້ຕ່າງໆ, glitches ແລະທັງຫມົດນັ້ນ, ຂອງທຸກສີແລະຂະຫນາດ, ແລະ. ຍັງ​ມີ​ເສັ້ນ​ຕາຍ​ທີ່​ເຄັ່ງ​ຄັດ​ຫຼາຍ. ໄປ​ກັນ​ເລີຍ!

ເນື້ອຫາ:

ການ​ຝຶກ​ອົບ​ຮົມ
ການປັບປຸງເຄື່ອງແມ່ຂ່າຍການຈັດການ
ການປັບປຸງກຸ່ມ

ນີ້ແມ່ນສິ່ງທີ່ພື້ນຖານໂຄງລ່າງຄລາວຂອງລູກຄ້າທົ່ວໄປທີ່ມີ Check Point virtual ເບິ່ງຄືວ່າ

ການ​ຝຶກ​ອົບ​ຮົມ

ຂັ້ນຕອນທໍາອິດແມ່ນເພື່ອກວດເບິ່ງວ່າມີຊັບພະຍາກອນພຽງພໍສໍາລັບການອັບເດດ. ຄວາມຕ້ອງການຂັ້ນຕ່ໍາທີ່ແນະນໍາສໍາລັບ R80.20 ໃນປັດຈຸບັນເບິ່ງຄືວ່ານີ້:

ອຸປະກອນ

CPU

RAM

HDD

ປະຕູຄວາມປອດໄພ

2 ຫຼັກ

4 Gb

ຈາກ 15 GB

ຂໍ້​ຄວາມ

2 ຫຼັກ

6 Gb

-

ຄໍາແນະນໍາແມ່ນໄດ້ອະທິບາຍໄວ້ໃນເອກະສານ CP_R80.20_GA_Release_Notes.

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

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

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

1. ພວກເຮົາເຊື່ອມຕໍ່ກັບ Smart Management Server ຜ່ານ ssh, ໄປທີ່ໂຫມດຜູ້ຊ່ຽວຊານແລະໃສ່ຄໍາສັ່ງ:

   [Expert@cp-sms:0]# df -h

2. ຢູ່ທີ່ຜົນຜະລິດພວກເຮົາຈະເຫັນບາງສິ່ງບາງຢ່າງເຊັ່ນ: ການຕັ້ງຄ່ານີ້:

   ຂະໜາດຂອງລະບົບໄຟລ໌ທີ່ໃຊ້ avail ໃຊ້ % Mounted on
   /dev/mapper/vg_splat-lv_current 30G 7.4G 21G 27% /
   /dev/sda1 289M 24M 251M 9% /boot
   tmpfs 2.0G 0 2.0G 0% /dev/shm
   /dev/mapper/vg_splat-lv_log 243G 177G 53G 78% /var/log

3. ໃນປັດຈຸບັນພວກເຮົາມີຄວາມສົນໃຈໃນພາກ / var / log

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

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

[Expert@cp-sms:0]# pvs

ພວກເຮົາຈະເຫັນບາງສິ່ງບາງຢ່າງເຊັ່ນນີ້:

PV VG Fmt Attr PSize PFree
/dev/sda3 vg_splat lvm2 a- 141.69G 43.69G

ໃນກໍລະນີນີ້ພວກເຮົາມີ 43 GB. ມີຊັບພະຍາກອນພຽງພໍ. ທ່ານ​ສາ​ມາດ​ເລີ່ມ​ຕົ້ນ​ການ​ປັບ​ປຸງ​.

ການປັບປຸງເຊີບເວີການຈັດການ Check Point SMS

ກ່ອນ​ທີ່​ຈະ​ເລີ່ມ​ຕົ້ນ​ການ​ເຮັດ​ວຽກ​, ທ່ານ​ຈໍາ​ເປັນ​ຕ້ອງ​ເຮັດ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

1. ຕິດຕັ້ງຊຸດເຄື່ອງມືການເຄື່ອນຍ້າຍໃນເຊີບເວີການຈັດການ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານຈໍາເປັນຕ້ອງໄດ້ດາວນ໌ໂຫລດຮູບພາບຈາກປະຕູໄດ້ Check Point.
2. ອັບໂຫລດແຟ້ມຈັດເກັບໄປຍັງເຊີບເວີການຈັດການຜ່ານ WinSCP ເຂົ້າໄປໃນໂຟນເດີ /var/log/UpgradeR77.30_R80.20 (ຖ້າຈໍາເປັນ, ສ້າງໂຟນເດີທໍາອິດ).
3. ເຊື່ອມຕໍ່ກັບເຊີບເວີການຈັດການຜ່ານ SSH ແລະໄປທີ່ໂຟນເດີທີ່ມີບ່ອນເກັບມ້ຽນ:cd /var/log/UpgradeR77.30_R80.20/
4. Unzip ໄຟລ໌:tar -zxvf ./<ຊື່ໄຟລ໌>.tgz
5. ພວກເຮົາເປີດຕົວ pre_upgrade_verifier utility ດ້ວຍຄໍາສັ່ງ: ./pre_upgrade_verifier -p $FWDIR -c R77 -t R80.20
6. ເມື່ອປະຕິບັດຄໍາສັ່ງ, ບົດລາຍງານກ່ຽວກັບການຕັ້ງຄ່າທີ່ບໍ່ເຂົ້າກັນຈະຖືກສ້າງຂຶ້ນ. ມັນສາມາດໃຊ້ໄດ້ຢູ່: /opt/CPsuite-R77/fw1/log/pre_upgrade_verification_report.(xls, html, txt). ມັນສະດວກກວ່າທີ່ຈະອັບໂຫລດມັນຜ່ານ SCP ແລະເບິ່ງມັນຜ່ານຕົວທ່ອງເວັບ.
   ເພື່ອແກ້ໄຂການຕັ້ງຄ່າທີ່ບໍ່ເຂົ້າກັນໄດ້, ໃຫ້ໃຊ້ SK117237.
7. ຫຼັງຈາກນັ້ນ, re-run utility pre_upgrade_verifier ເພື່ອໃຫ້ແນ່ໃຈວ່າສາເຫດຂອງຄວາມບໍ່ເຂົ້າກັນທັງຫມົດໄດ້ຖືກລົບລ້າງ.
8. ຕໍ່ໄປ, ພວກເຮົາເກັບກໍາຂໍ້ມູນກ່ຽວກັບການໂຕ້ຕອບເຄືອຂ່າຍ, ຕາຕະລາງການກໍານົດເສັ້ນທາງແລະອັບໂຫລດການຕັ້ງຄ່າ GAIA:
   ip a > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
   ip r > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
   clish -c "show configuration" > /var/log/UpgradeR77.30_R80.20/cp-sms-config.txt
9. ອັບໂຫຼດໄຟລ໌ຜົນໄດ້ຮັບຜ່ານ SCP.
10. ພວກເຮົາຖ່າຍຮູບໃນລະດັບ virtualization.
11. ພວກເຮົາເພີ່ມເວລາຫມົດເວລາຂອງກອງປະຊຸມ SSH ເປັນ 8 ຊົ່ວໂມງ. ມັນຂຶ້ນຢູ່ກັບໂຊກຂອງທ່ານ: ອີງຕາມຂະຫນາດຂອງຖານຂໍ້ມູນທີ່ສົ່ງອອກ, ມັນສາມາດຢູ່ໄດ້ຈາກຫຼາຍນາທີເຖິງຫຼາຍຊົ່ວໂມງ. ສໍາລັບການນີ້: 
    [Expert@HostName]# clish -c "show inactivity-timeout" ເບິ່ງ​ການ​ກໍາ​ນົດ​ເວ​ລາ​ປະ​ຈຸ​ບັນ​,

    [Expert@HostName]# clish -c "ຕັ້ງ inactivity-timeout 720" ລະບຸການໝົດເວລາໃໝ່ (ເປັນນາທີ),

    [Expert@HostName]# ສະທ້ອນ $TMOUT ເບິ່ງຮູບແບບຜູ້ຊ່ຽວຊານການໝົດເວລາໃນປັດຈຸບັນ,

    [Expert@HostName]# ສົ່ງອອກ TMOUT=3600 ລະບຸຮູບແບບຜູ້ຊ່ຽວຊານການໝົດເວລາໃໝ່ (ເປັນວິນາທີ), ຖ້າທ່ານຕັ້ງຄ່າເປັນ 0, ເວລາໝົດເວລາຈະຖືກປິດໃຊ້ງານ.

12. ພວກເຮົາດາວໂຫລດແລະຕິດຕັ້ງຮູບພາບການຕິດຕັ້ງ SMS.iso ກັບເຄື່ອງ virtual.

    ກ່ອນຂັ້ນຕອນຕໍ່ໄປ, ໃຫ້ແນ່ໃຈວ່າທ່ານກວດເບິ່ງສອງຄັ້ງວ່າທ່ານມີພື້ນທີ່ບໍ່ຖືກຈັດສັນພຽງພໍໃນຮາດໄດຂອງທ່ານ (ຈື່, ທ່ານຕ້ອງການ 13 GB). 

13. ກ່ອນທີ່ຈະເລີ່ມສົ່ງອອກການຕັ້ງຄ່າ, ປ່ຽນໄຟລ໌ບັນທຶກດ້ວຍຄໍາສັ່ງ: fw ເຂົ້າສູ່ລະບົບ

ສົ່ງອອກການຕັ້ງຄ່າ ແລະບັນທຶກ

1. ແລ່ນ utility migrate_export ເພື່ອດາວໂຫລດການຕັ້ງຄ່າ. ເພື່ອເຮັດສິ່ງນີ້, ໄປທີ່ໂຟນເດີທີ່ສ້າງຂຶ້ນກ່ອນຫນ້ານີ້: cd /var/log/UpgradeR77.30_R80.20/ ແລະໃຊ້ຄໍາສັ່ງ: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

   ຫຼື

   ໄປທີ່ໂຟນເດີ: cd $FWDIR/bin/upgrade_tools/ и
   ດໍາເນີນການຄໍາສັ່ງຈາກບ່ອນນັ້ນ: ./migrate export -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

2. ພວກເຮົາເອົາ checksum ອອກຈາກບ່ອນເກັບມ້ຽນ: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz
3. ບັນທຶກມູນຄ່າຜົນໄດ້ຮັບໃສ່ notepad.
4. ພວກເຮົາເຊື່ອມຕໍ່ກັບ SMS ຜ່ານ SCP ແລະອັບໂຫລດແຟ້ມຈັດເກັບດ້ວຍການຕັ້ງຄ່າໄປຍັງບ່ອນເຮັດວຽກ. ໃຫ້ແນ່ໃຈວ່າໃຊ້ການໂອນໄຟລ໌ໃນຮູບແບບຖານສອງ.

ສົ່ງອອກຖານຂໍ້ມູນ SmartEvent

ໃນ​ທີ່​ນີ້​ພວກ​ເຮົາ​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຕິດ​ຕັ້ງ SMS ເວີ​ຊັນ R80 ກ່ອນ​. ການທົດສອບໃດໆຈະເຮັດ. 

1. ຈາກ SMS ພວກເຮົາຕ້ອງການສະຄິບທີ່ຢູ່ບ່ອນນີ້:$RTDIR/bin/eva_db_backup.csh
2. ໂຫລດສະຄຣິບຜ່ານ SCP eva_db_backup.csh ໄປທີ່ໂຟນເດີ: /var/log/UpgradeR77.30_R80.20/
3. ເຊື່ອມຕໍ່ຜ່ານ SSH ກັບ SMS. ສຳເນົາໄຟລ໌ໃສ່ໂຟນເດີ: cp /var/log/UpgradeR77.30_R80.20/eva_db_backup.csh
   $RTDIR/bin/eva_db_backup.csh
4. ການ​ປ່ຽນ​ແປງ​ການ​ເຂົ້າ​ລະ​ຫັດ​: dos2unix $RTDIR/bin/eva_db_backup.csh
5. ເພີ່ມເຈົ້າຂອງ: chown -v admin: root $RTDIR/bin/eva_db_backup.csh
6. ເພີ່ມສິດ: chmod -v 0755 $RTDIR/bin/eva_db_backup.csh
7. ມາເລີ່ມການສົ່ງອອກຖານຂໍ້ມູນ SmartEvent: $RTDIR/bin/eva_db_backup.csh
8. ອັບໂຫລດໄຟລ໌ທີ່ໄດ້ຮັບຜ່ານ SCP: $RTDIR/bin/<date>-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar ໄປຫາສະຖານີເຮັດວຽກ.

ປັບປຸງໃຫ້ທັນ

1. ໄປ​ຫາ WebUI GAIA SMS → CPUSE → ສະແດງແພັກເກັດທັງໝົດ.
2. ຖ້າ CPUSE ມີຂໍ້ຜິດພາດໃນການເຊື່ອມຕໍ່ກັບ Check Point cloud, ໃຫ້ກວດເບິ່ງການຕັ້ງຄ່າ DGW, DNS ແລະ Proxy.
3. ຖ້າທຸກສິ່ງທຸກຢ່າງຖືກຕ້ອງ, ແລະຄວາມຜິດພາດບໍ່ຫາຍໄປ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ປັບປຸງ CPUSE ດ້ວຍຕົນເອງ, ນໍາພາໂດຍ. sk92449.
4. ດາວ​ນ​໌​ໂຫລດ​ຮູບ​ພາບ​ແລະ​ໄປ​ໂດຍ​ຜ່ານ​ການ​ ຕົວກວດສອບ. ຖ້າຈໍາເປັນ, ພວກເຮົາກໍາຈັດຄວາມບໍ່ສອດຄ່ອງ.

   ດັ່ງນັ້ນ, ທ່ານຄວນເຫັນຂໍ້ຄວາມນີ້:

   

5. ເລືອກ R80.20 ການຕິດຕັ້ງແລະຍົກລະດັບໃຫມ່ສໍາລັບການຄຸ້ມຄອງຄວາມປອດໄພ.
6. ເມື່ອຕິດຕັ້ງການປັບປຸງ, ເລືອກ Clean Install. ຫຼັງຈາກການຕິດຕັ້ງ, ລະບົບຈະ reboot.
7. ພວກເຮົາຜ່ານຄັ້ງທໍາອິດ ຂອງຄວາມຍາວປາ.
8. ຫຼັງຈາກການເຂົ້າເຖິງ, ພວກເຮົາກວດເບິ່ງບັນຊີ.
9. ພວກເຮົາເຊື່ອມຕໍ່ກັບ SMS ຜ່ານ SSH ແລະປ່ຽນ shell ຂອງຜູ້ໃຊ້ຂອງພວກເຮົາເປັນ /bin/bash/:

   ຕັ້ງຜູ້ໃຊ້ <ຊື່ຜູ້ໃຊ້> shell /bin/bash/

   ບັນທຶກການຕັ້ງຄ່າ (ໃນກໍລະນີທີ່ພວກເຮົາຕ້ອງການອອກຈາກ bin/bash/ ເປັນ shell ເລີ່ມຕົ້ນຫຼັງຈາກ reboot).

10. ຕໍ່ໄປ, ພວກເຮົາເຊື່ອມຕໍ່ກັບ SMS ຜ່ານ SCP ແລະໂອນຮວບຮວມດ້ວຍການຕັ້ງຄ່າໃນຮູບແບບ Binary SMS_w_logs_export_r77_r80.tgz ໄປຫາໂຟນເດີ /var/log/UpgradeR77.30_R80.20/
    
11. ພວກເຮົາເອົາ checksum ອອກຈາກບ່ອນເກັບມ້ຽນ: md5sum /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz ແລະປຽບທຽບກັບມູນຄ່າທີ່ຜ່ານມາ. Checksum ຕ້ອງກົງກັນ.
12. ພວກເຮົາເພີ່ມເວລາຫມົດເວລາຂອງກອງປະຊຸມ SSH ເປັນ 8 ຊົ່ວໂມງ. ສໍາລັບການນີ້:

    [Expert@HostName]# clish -c "show inactivity-timeout" ເບິ່ງ​ການ​ກໍາ​ນົດ​ເວ​ລາ​ປະ​ຈຸ​ບັນ​,

    [Expert@HostName]# clish -c "ຕັ້ງ inactivity-timeout 720" ລະບຸການໝົດເວລາໃໝ່ (ເປັນນາທີ),

    [Expert@HostName]# ສະທ້ອນ $TMOUT ເບິ່ງຮູບແບບຜູ້ຊ່ຽວຊານການໝົດເວລາໃນປັດຈຸບັນ,

    [Expert@HostName]# ສົ່ງອອກ TMOUT=3600 ລະບຸໂໝດຜູ້ຊ່ຽວຊານໝົດເວລາໃໝ່ (ເປັນວິນາທີ). ຖ້າທ່ານຕັ້ງຄ່າເປັນ 0, ເວລາໝົດເວລາຈະຖືກປິດໃຊ້ງານ.

13. ເພື່ອນໍາເຂົ້າການຕັ້ງຄ່າ, ດໍາເນີນການນໍາໃຊ້ເຄື່ອງມືການນໍາເຂົ້າການເຄື່ອນຍ້າຍ. ເພື່ອເຮັດສິ່ງນີ້, ໄປທີ່ໂຟນເດີ: cd $FWDIR/bin/upgrade_tools/ແລະດໍາເນີນການນໍາເຂົ້າ: ./migrate imp
    ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

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

ລາຍ​ການ​ກວດ​ສອບ​ຫຼັງ​ຈາກ​ການ​ປັບ​ປຸງ​

1. ການມີຊັບພະຍາກອນ.
2. SIC ກັບ GW.
3. ໃບອະນຸຍາດ. ຖ້າໃບອະນຸຍາດຖືກສະແດງບໍ່ຖືກຕ້ອງຫຼືບໍ່ໄດ້ສະແດງຢູ່ໃນ SMS, ດໍາເນີນການຄໍາສັ່ງ vsec_central_licence ສໍາລັບການແຈກຢາຍໃບອະນຸຍາດ.
4. ກໍານົດນະໂຍບາຍ. 

ກຳລັງນຳເຂົ້າຖານຂໍ້ມູນ SmartEvent

1. ເປີດໃຊ້ໃບ SmartEvent.
2. ພວກເຮົາເຊື່ອມຕໍ່ຜ່ານ WinSCP ກັບ SMS ແລະໂອນໄຟລ໌ທີ່ດາວໂຫລດມາກ່ອນຫນ້ານີ້ໃນຮູບແບບສອງ <date>-db-backup.backup и eventiaUpgrade.tar ໄປຫາໂຟນເດີ /var/log/UpgradeR77.30_R80.20/
3. ພວກເຮົາດໍາເນີນການ script ດ້ວຍຄໍາສັ່ງ: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
4. ການ​ກວດ​ສອບ​ສະ​ຖາ​ນະ​ພາບ​: ເບິ່ງ -n 10 eventiaUpgrade.sh
5. ກວດເບິ່ງບັນທຶກໃນ SmartEvent. ຝັນ!

ການອັບເດດ Check Point GW cluster (Active/Backup)

ກ່ອນທີ່ຈະເລີ່ມເຮັດວຽກ

1. ພວກເຮົາບັນທຶກການຕັ້ງຄ່າ GAIA ຈາກແຕ່ລະ node cluster ໄປຫາໄຟລ໌, ເພື່ອເຮັດສິ່ງນີ້, ໃຊ້ຄໍາສັ່ງ: clish -c "show configuration" > ./<ຊື່ໄຟລ໌>.txt
2. ການອັບໂຫລດໄຟລ໌ໂດຍໃຊ້ WinSCP.
3. ເຊື່ອມຕໍ່ຫາ WebUI ຂອງທັງສອງ nodes ແລະໄປທີ່ແຖບ CPUSE → ສະແດງແພັກເກັດທັງໝົດ.
4. ຊອກຫາຊຸດການປັບປຸງສໍາລັບສະບັບ R80.20 ຕິດຕັ້ງສົດ, ກົດ ດາວໂຫລດ.
5. ພວກເຮົາກວດເບິ່ງວ່າໂປໂຕຄອນ CCP ເຮັດວຽກຢູ່ໃນໂຫມດ ອອກອາກາດເພື່ອເຮັດສິ່ງນີ້, ໃສ່ຄໍາສັ່ງ: cphaprob -a ຖ້າ
   ຖ້າເລືອກຮູບແບບ Multicast, ແທນທີ່ມັນດ້ວຍຄໍາສັ່ງ: cphaconf set_ccp ອອກອາກາດ (ຄໍາສັ່ງຖືກປະຕິບັດໃນແຕ່ລະ node).
6. ພວກເຮົາຕິດຕັ້ງ Downtime ສໍາລັບ nodes ທີ່ກ່ຽວຂ້ອງໃນລະບົບການຕິດຕາມຂອງທ່ານ.
7. ພວກເຮົາກວດເບິ່ງວ່າຕົວກໍານົດການໄດ້ຖືກເປີດໃຊ້ຢູ່ໃນລະດັບ virtualization ການປ່ຽນແປງທີ່ຢູ່ MAC и ການສົ່ງຜ່ານປອມ ສໍາລັບເຄືອຂ່າຍ sync.

ປັບປຸງໃຫ້ທັນ

1. ພວກເຮົາເຊື່ອມຕໍ່ຜ່ານ ssh ກັບ Active node ແລະດໍາເນີນການຄໍາສັ່ງເພື່ອຕິດຕາມກວດກາສະຖານະຂອງກຸ່ມ: watch -n 2 cphaprob ສະຖິຕິ
2. ກັບໄປທີ່ແຖບ nodes WebUI Stanby CPUSE ແລະສໍາລັບຊຸດທີ່ເລືອກ R80.20 ຕິດຕັ້ງສົດ ເປີດຕົວ ຕົວກວດສອບ.
3. ມາວິເຄາະລາຍງານຕົວກວດສອບ. ຖ້າການຕິດຕັ້ງຖືກອະນຸຍາດໃຫ້, ຍ້າຍອອກໄປ.
4. ເລືອກຊຸດ R80.20 ຕິດຕັ້ງສົດ ແລະແລ່ນ ການຍົກລະດັບ. ໃນ​ລະ​ຫວ່າງ​ການ​ຂະ​ບວນ​ການ​ຍົກ​ລະ​ດັບ​, ລະ​ບົບ​ຈະ reboot​. ການຕັ້ງຄ່າ GAIA ຖືກບັນທຶກໄວ້. ໃນເວລາທີ່ reboot, ພວກເຮົາຕິດຕາມກວດກາສະຖານະຂອງ cluster ໄດ້. ຫຼັງ​ຈາກ​ການ​ໂຫຼດ​, ສະ​ຖາ​ນະ​ຂອງ node ການ​ປັບ​ປຸງ​ຄວນ​ຈະ​ປ່ຽນ​ເປັນ READY​. ໃນຫຼາຍໆກໍລະນີ, ພວກເຮົາພົບກັບຊ່ວງເວລາທີ່ໂຫນດທີ່ຍັງບໍ່ທັນໄດ້ຮັບການປັບປຸງໄດ້ສະຫຼັບກັບສະຖານະ Active Attention ແລະຢຸດສະແດງສະຖານະຂອງໂຫນດທີ່ຖືກປັບປຸງ. ບໍ່ຕ້ອງຕົກໃຈ - ທາງເລືອກນີ້ຍັງຍອມຮັບໄດ້.
5. ເມື່ອການອັບເດດສໍາເລັດ, ເປີດ SmartDashboard.
6. ເປີດວັດຖຸກຸ່ມ ແລະປ່ຽນເວີຊັນຂອງກຸ່ມຈາກ R77.30 ເປັນ R80.20. ກົດ OK. ຖ້າມີຂໍ້ຜິດພາດປະກົດຂຶ້ນໃນເວລາບັນທຶກການປ່ຽນແປງ:
   ເກີດຄວາມຜິດພາດພາຍໃນ. (ລະຫັດ: 0x8003001D, ບໍ່ສາມາດເຂົ້າເຖິງໄຟລ໌ສໍາລັບການດໍາເນີນການຂຽນ),
   ປະຕິບັດຕາມ SK119973. ຫຼັງຈາກນັ້ນ, ບັນທຶກການປ່ຽນແປງແລະກົດ ນະໂຍບາຍການຕິດຕັ້ງ.
7. ໃນການຕັ້ງຄ່າ, ຍົກເລີກການເລືອກທາງເລືອກ ສຳລັບກຸ່ມ gateway, ຖ້າການຕິດຕັ້ງຢູ່ໃນກຸ່ມສະມາຊິກລົ້ມເຫລວ, ຢ່າຕິດຕັ້ງໃສ່ cluster ນັ້ນ.
8. ພວກເຮົາກໍານົດນະໂຍບາຍ. ລະບົບຈະສ້າງຄວາມຜິດພາດສໍາລັບ node Active ທີ່ຍັງບໍ່ທັນໄດ້ປັບປຸງ.
9. ພວກເຮົາເຊື່ອມຕໍ່ກັບ node ປັບປຸງຜ່ານ ssh ແລະດໍາເນີນການຄໍາສັ່ງເພື່ອຕິດຕາມກວດກາສະຖານະຂອງກຸ່ມ: watch -n 2 cphaprob ສະຖິຕິ
10. ເຊື່ອມຕໍ່ຫາ WebUI Active node ແລະໄປທີ່ແຖບ CPUSE → ສະແດງແພັກເກັດທັງໝົດ.ຊອກຫາຊຸດການປັບປຸງສໍາລັບສະບັບ R80.20 ຕິດຕັ້ງສົດ, ຄລິກ ດາວໂຫລດ.
11. ພວກເຮົາຕິດຕັ້ງ Downtime ສໍາລັບ nodes ທີ່ກ່ຽວຂ້ອງໃນລະບົບການຕິດຕາມຂອງທ່ານ.
12. ກັບໄປທີ່ແຖບ WebUI Active nodes CPUSE ແລະສໍາລັບຊຸດທີ່ເລືອກ R80.20 ຕິດຕັ້ງສົດ ເປີດຕົວ ຕົວກວດສອບ.
13. ມາວິເຄາະລາຍງານຕົວກວດສອບ. ຖ້າການຕິດຕັ້ງຖືກອະນຸຍາດໃຫ້, ຍ້າຍອອກໄປ.
14. ເລືອກຊຸດ R80.20 ຕິດຕັ້ງສົດ ແລະແລ່ນ ຍົກລະດັບ. ໃນ​ລະ​ຫວ່າງ​ການ​ຂະ​ບວນ​ການ​ຍົກ​ລະ​ດັບ​, ລະ​ບົບ​ຈະ reboot​. ການຕັ້ງຄ່າ GAIA ຖືກບັນທຶກໄວ້. ໃນເວລາທີ່ reboot, ພວກເຮົາຕິດຕາມກວດກາສະຖານະຂອງ cluster ໃນ node ປັບປຸງແລ້ວ. ຫຼັງຈາກປິດເປີດໃໝ່, ສະຖານະຂອງກຸ່ມຢູ່ໃນໂນດທີ່ອັບເດດແລ້ວຈະປ່ຽນຈາກ READY ເປັນ ACTIVE.
15. ເມື່ອຂະບວນການອັບເກຣດສຳເລັດແລ້ວ, ເປີດ SmartDashboard ແລະຕັ້ງນະໂຍບາຍ.

ລາຍ​ການ​ກວດ​ສອບ​ຫຼັງ​ຈາກ​ການ​ປັບ​ປຸງ​

• ບັນທຶກເຫດການໃນ SmartLog, ສະຖານະຂອງອຸໂມງ VPN.
• ການຕັ້ງຄ່າ GAIA.
• ການຟື້ນຟູກຸ່ມຫຼັງຈາກການທົດສອບ Failover.
• ໃບອະນຸຍາດແລະສັນຍາ. ຖ້າໃບອະນຸຍາດຖືກສະແດງບໍ່ຖືກຕ້ອງຫຼືບໍ່ໄດ້ສະແດງຢູ່ໃນ SMS, ດໍາເນີນການຄໍາສັ່ງ. vsec_central_licence ສໍາລັບການແຈກຢາຍໃບອະນຸຍາດ.
• CoreXL.
• SecureXL.
• Hotfix ແລະ CPinfo ໃນສອງ nodes.

ສະຫລຸບ

ໂດຍທົ່ວໄປ, ນັ້ນແມ່ນທັງຫມົດໃນຈຸດນີ້ - ທ່ານໄດ້ຮັບການປັບປຸງ.

ສໍາລັບພວກເຮົາ, ຂະບວນການທັງຫມົດໃຊ້ເວລາໂດຍສະເລ່ຍຈາກ 6 ຫາ 12 ຊົ່ວໂມງ, ຂຶ້ນກັບຂະຫນາດຂອງຖານຂໍ້ມູນທີ່ສົ່ງອອກ. ວຽກງານດັ່ງກ່າວໄດ້ດໍາເນີນໃນໄລຍະສອງຄືນ: ຫນຶ່ງສໍາລັບການອັບເດດ SMS, ທີສອງສໍາລັບກຸ່ມ.

ບໍ່ມີການຢຸດການຈາລະຈອນ, ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າພວກເຮົາໄດ້ກວດເບິ່ງຂໍ້ຜິດພາດທີ່ໄດ້ກ່າວມາຂ້າງເທິງທັງຫມົດໃນຕົວເຮົາເອງ.

ແນ່ນອນ, ບາງຄັ້ງຄວາມຫຍຸ້ງຍາກໃຫມ່ຫມົດອາດຈະເກີດຂື້ນໃນລະຫວ່າງຂະບວນການປັບປຸງ, ແຕ່ນີ້ແມ່ນ Check Point, ແລະດັ່ງທີ່ພວກເຮົາທຸກຄົນຮູ້, ສະເຫມີມີ hotfix!

ສຸກສັນຄືນສີດຳ ແລະສີບົວ ແລະອັບເດດ!

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