ProHoster > блог > адміністраванне > Абнаўляем Check Point з R77.30 на 80.20

Абнаўляем Check Point з R77.30 на 80.20

Абнаўляем Check Point з R77.30 на 80.20

Увосень 2019 гады Check Point спыніў падтрымку версій R77.XX, і трэба было абнаўляцца. Аб розніцы паміж версіямі, плюсах і мінусах пераходу на R80 сказанае ўжо нямала. Давайце лепш пагаворым аб тым, як, уласна, абнавіць віртуальныя appliance Check Point (CloudGuard для VMware ESXi, Hyper-V, KVM Gateway NGTP) і што можа пайсці не так.

Такім чынам, у нас было 2 інжынера CCSE, больш за дзесятак віртуальных кластараў Check Point R77.30, некалькі аблокаў, трошачкі хотфіксаў і цэлае мора разнастайных багаў, глюкаў і ўсяго такога, усіх кветак і памераў, а яшчэ вельмі сціснутыя тэрміны. Пагналі!

Змест:

Падрыхтоўка
Абнаўляем сервер кіравання
Абнаўляем кластар

Абнаўляем Check Point з R77.30 на 80.20

Так выглядае тыповая хмарная інфраструктура кліента з віртуальным Check Point

Падрыхтоўка

Перш за ўсё трэба праверыць дастатковасць рэсурсаў для абнаўлення. Рэкамендаваныя мінімальныя патрабаванні для R80.20 зараз выглядаюць так:

Прылада

CPU

RAM

Жорсткі дыск

Шлюз бяспекі

Ядро 2

4 Gb

Ад 15 GB

SMS

Ядро 2

6 Gb

-

Рэкамендацыі апісаны ў дакуменце CP_R80.20_GA_Release_Notes.

Але мы будзем рэалістамі. Калі ў самай мінімальнай канфігурацыі гэтага дастаткова, то, як паказвае практыка, звычайна ў нас уключана https-інспекцыя, на SMS працуе SmartEvent і г.д., што, зразумела, патрабуе зусім іншых магутнасцей. Але ў цэлым не вялікіх, чым для R77.30.

Але ёсць нюансы. І датычацца яны, у першую чаргу, памераў фізічнай памяці. Многія аперацыі непасрэдна ў працэсе абнаўлення запатрабуюць месцы на цвёрдым дыску.

Для сервера кіравання памер вольнай прасторы на дыску будзе вельмі моцна залежаць ад аб'ёму бягучых логаў (калі мы жадаем іх захаваць) і ад колькасці захаваных Database Revisions, хоць яны вось нам у вялікай колькасці ўжо не спатрэбяцца. Зразумела, для нод кластара (калі толькі вы не захоўваеце логі яшчэ і лакальна) гэта ўсё не мае значэння. Вось як можна праверыць наяўнасць неабходнага месца:

  1. Падлучаемся да Smart Management Server па ssh, заходзім у expert mode і ўводны каманду:

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

  2. На выхадзе мы ўбачым прыкладна такую ​​канфігурацыю:

    Filesystem Size Used Avail Use% 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. Нас у дадзены момант цікавіць падзел / Вар / часопіс

Улічвайце, што ў залежнасці ад палітыкі захоўвання і выдаленні старых лог-файлаў, а таксама памеру экспартуемай базы можа спатрэбіцца больш месца. Калі пры стварэнні архіва вольнага месца стане менш, чым паказана ў палітыцы захоўвання лог-файлаў, сістэма пачне сціраць старыя логі і НЕ уключыць іх у архіў.

Таксама для самога працэсу абнаўлення сістэме спатрэбіцца мінімум 13 GB неразмеркаванага месца на цвёрдай кружэлцы. Праверыць яго наяўнасць можна камандай:

[Expert@cp-sms:0]# pvs

Убачым прыблізна вось такая выснова:

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

У дадзеным выпадку мы маем 43 Гб. Рэсурсаў хапае. Можна прыступаць да абнаўлення.

Абнаўляем сервер кіравання Check Point SMS

Перад пачаткам прац трэба зрабіць наступнае:

  1. Усталеўваны пакет Migration Tools на сервер кіравання. Для гэтага неабходна выгрузіць выяву з партала Пункт кантролю.
  2. Загружаем архіў на сервер кіравання праз WinSCP у тэчку /var/log/UpgradeR77.30_R80.20 (калі трэба, то папярэдне стварыць тэчку).
  3. Падключаемся да сервера кіравання праз SSH і прайсці ў тэчку з архівам:cd /var/log/UpgradeR77.30_R80.20/
  4. Разархівуем файл:tar -zxvf ./<назва файла>.tgz
  5. Запускаем утыліту pre_upgrade_verifier камандай: ./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. Пасля паўторна запусціць утыліту 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. Які робіцца snapshot на ўзроўні віртуалізацыі.
  11. Павялічваем timeout SSH сесіі да 8 гадзін. Тут як пашанцуе: у залежнасці ад памераў экспартуемай базы можа працягвацца ад некалькіх хвілін да некалькіх гадзін. Для гэтага: 
    [Expert@HostName]# clish -c "show inactivity-timeout" глядзім бягучы timeout clish,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" паказваем новы timeout clish (у хвілінах),

    [Expert@HostName]# echo $TMOUT глядзім бягучы timeout expert mode,

    [Expert@HostName]# export TMOUT=3600 паказваем новы timeout expert mode (у секундах), калі паставіць значэнне 0, то timeout будзе выключаны.

  12. Падгружаем і мантуем усталявальны вобраз SMS.iso да віртуальнай машыны.

    Перад наступным крокам АБАВЯЗКОВА яшчэ раз праверце, што ў вас дастаткова неразмеркаванага месца на цвёрдым дыску (нагадаю, трэба 13 GB). 

  13. Перад пачаткам экспарту канфігурацыі змяняем лог файл камандай: fw logswitch

Экспарт канфігурацыі і логаў

  1. Запускаем утыліту 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. Захоўваем у блакнот атрыманае значэнне.
  4. Падлучаемся да SMS праз SCP і выгружаем архіў з канфігурацыяй на працоўную станцыю. Абавязкова выкарыстоўваць перадачу файлаў у фармаце Binary.

Экспарт базы 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. Запускаем экcпорт базы SmartEvent: $RTDIR/bin/eva_db_backup.csh
  8. Выгружаем атрыманыя файлы праз SCP: $RTDIR/bin/<дата>-db-backup.backup и $RTDIR/bin/eventiaUpgrade.tar на працоўную станцыю.

Абнаўленне

  1. пераходзім у WebUI GAIA SMS → CPUSE → Show all packages.
  2. У выпадку, калі CPUSE выдае памылку падлучэння да воблака Check Point, правяраем DGW, DNS і налады Proxy.
  3. Калі ўсё дакладна, а памылка не знікае, тое трэба абнавіць CPUSE уручную, кіруючыся sk92449.
  4. Спампоўваем вобраз і праходзім Verifier. У выпадку неабходнасці ўстараняем неадпаведнасці.

    У выніку павінны ўбачыць вось такое паведамленне:

    Абнаўляем Check Point з R77.30 на 80.20

  5. выбіраем R80.20 Fresh Install and Upgrade для аховы здароўя.
  6. Пры ўсталёўцы абнаўлення выбіраемы Clean Install. Пасля ўсталёўкі сістэма перазагрузіцца.
  7. Праходзім First Time Майстар.
  8. Пасля атрымання доступу правяраем уліковыя запісы.
  9. Падлучаемся да SMS па SSH і змяняем shell нашага карыстача на /bin/bash/:

    set user <імя карыстальніка> shell /bin/bash/

    захаваць канфігурацыю (у выпадку, калі мы жадаем пакінуць bin/bash/ як shell па змаўчанні і пасля перазагрузкі).

  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. Павялічваем timeout SSH сесіі да 8 гадзін. Для гэтага:

    [Expert@HostName]# clish -c "show inactivity-timeout" глядзім бягучы timeout clish,

    [Expert@HostName]# clish -c "set inactivity-timeout 720" паказваем новы timeout clish (у хвілінах),

    [Expert@HostName]# echo $TMOUT глядзім бягучы timeout expert mode,

    [Expert@HostName]# export TMOUT=3600 паказваем новы timeout expert mode (у секундах). Калі паставіць значэнне 0, то timeout будзе выключаны.

  13. Для імпарту настроек запускаем утыліту migrate import. Для гэтага пераходзім у тэчку: cd $FWDIR/bin/upgrade_tools/і запускаем імпарт: ./migrate imp
    ort -l /var/log/UpgradeR77.30_R80.20/SMS_w_logs_export_r77_r80.tgz

Атрымліваем асалоду ад жыццём бліжэйшыя пару гадзін. НЕ АДКЛЮЧАЙЦЕ SSH-СЕСІЮ падчас працэдуры. У канцы працэс migrate выдасць або паведамленне аб паспяховым завяршэнні аперацыі, або памылку. 

Чэк-ліст праверак пасля абнаўлення

  1. Даступнасць рэсурсаў.
  2. SIC з GW.
  3. Ліцэнзіі. Калі ліцэнзіі адлюстроўваюцца няправільна або не адлюстроўваюцца на SMS, запускаем каманду vsec_central_licence для размеркавання ліцэнзій.
  4. Устаноўка палітыкі. 

Імпарт базы SmartEvent

  1. Актывуйце блейд SmartEvent.
  2. Падлучаемся праз WinSCP да SMS і ў рэжыме binary перадаем выгружаныя раней файлы <дата>-db-backup.backup и eventiaUpgrade.tar у тэчку /var/log/UpgradeR77.30_R80.20/
  3. Запускаем скрыпт камандай: $RTDIR/bin/eventiaUpgrade.sh -upgrade /var/log/UpgradeR77.30_R80.20/eventiaUpgrade.tar
  4. Правяраем статус: watch -n 10 eventiaUpgrade.sh
  5. Правяраем логі ў SmartEvent. СОН!

Абнаўляем кластар Check Point GW (Active/Backup)

Перад пачаткам прац

  1. Захоўваем канфігурацыю GAIA з кожнай ноды кластара ў файл, для гэтага скарыстацца камандай: clish -c "show configuration" > ./<Назва файла>.txt
  2. Выгружаем файлы пры дапамозе WinSCP.
  3. Падлучаемся да WebUI абедзвюх нод і пераходзім на ўкладку CPUSE → Show all packages.
  4. Знаходзім пакет абнаўленняў для версіі R80.20 Fresh Install, націскаем Спампаваць.
  5. Правяраем, што CCP-пратакол працуе ў рэжыме Вroadcast, для гэтага ўводзім каманду: cphaprob -a if
    Калі абраны рэжым Multicast, зменіце яго камандай: cphaconf set_ccp broadcast (каманда выконваецца на кожнай нодзе).
  6. Усталёўваны Downtime для задзейнічаных нод у вашай сістэме маніторынгу.
  7. Правяраем, што на ўзроўні віртуалізацыі ўключаны параметры Змена MAC-адраса и Forged Transmits для sync-сеткі.

Абнаўленне

  1. Падлучаемся па ssh да Active-нодзе і запускаем каманду для маніторынгу стану кластара: watch -n 2 cphaprob stat
  2. Вяртаемся ў WebUI Stanby ноды на ўкладку CPUSE і для абранага пакета R80.20 Fresh Install запускаем Verifier.
  3. Аналізуем справаздачу Verifier. Калі ўстаноўка дазволена, ідзем далей.
  4. Выбіраемы пакет R80.20 Fresh Install і запускаем мадэрнізацыя. У працэсе Upgrade сістэма будзе перазагружана. Настройкі GAIA захоўваюцца. У момант перазагрузкі адсочваем стан кластара. Пасля загрузкі статут абноўленай ноды павінен змяніцца на READY. У шэрагу выпадкаў у нас узнікаў момант, калі яшчэ не абноўленая нода пераходзіла ў статут Active Attention і пераставала адлюстроўваць статут абноўленай ноды. Не палохайцеся - такі варыянт таксама дапусцім.
  5. Па завяршэнні абнаўлення адкрываем SmartDashboard.
  6. Адкрываем кластарны аб'ект і змяняем версію кластара з R77.30 на R80.20. Ціснем Ок. Калі пры захаванні змен з'яўляецца памылка:
    An internal error has occurred. (Code: 0x8003001D, Выкарыстоўвайце не access file for write operation),
    прытрымлівайцеся SK119973. Пасля гэтага захоўваем змены і ціснем Install Policy.
  7. У наладах прыбіраем галачку з параметру Для гатэляў clusters, калі ўладкавацца на cluster member fails, do no install on cluster.
  8. Усталёўваны палітыку. Сістэма выдасць памылку для Active-ноды, якая яшчэ не абноўлена.
  9. Падлучаемся да абноўленай ноды па ssh і запускаем каманду для маніторынгу стану кластара: watch -n 2 cphaprob stat
  10. Падлучаемся да WebUI Active-ноды і пераходзім ва ўкладку CPUSE → Show all packages.Знаходзім пакет абнаўленняў для версіі R80.20 Fresh Install, ціснем Спампаваць.
  11. Усталёўваны Downtime для задзейнічаных нод у вашай сістэме маніторынгу.
  12. Вяртаемся ў WebUI Active-ноды на ўкладку CPUSE і для абранага пакета R80.20 Fresh Install запускаем Verifier.
  13. Аналізуем справаздачу Verifier. Калі ўстаноўка дазволена, ідзем далей.
  14. Выбіраемы пакет R80.20 Fresh Install і запускаем Абнаўленне. У працэсе Upgrade сістэма будзе перазагружана. Настройкі GAIA захоўваюцца. У момант перазагрузкі адсочваем стан кластара на ўжо абноўленай надзе. Пасля перазагрузкі стан кластара на абноўленай нодзе зменіцца з READY на ACTIVE.
  15. Калі завершыцца працэс Upgrade, запускаем SmartDashboard і ўсталёўваны палітыку.

Чэк-ліст праверак пасля абнаўлення

  • Часопісы падзей у SmartLog, стан VPN-тунэляў.
  • Настройкі GAIA.
  • Аднаўленне кластара пасля тэставага Failover.
  • Ліцэнзіі і кантракты. У выпадку, калі ліцэнзіі адлюстроўваюцца няправільна альбо не адлюстроўваюцца на SMS, запускаем каманду. vsec_central_licence для размеркавання ліцэнзій.
  • CoreXL.
  • SecureXL.
  • Hotfix і CPinfo на двух нодах.

Заключэнне

Увогуле-то на гэтым моманце ўсё - вы абнавіліся.

У нас увесь працэс займаў у сярэднім ад 6 да 12 гадзін, у залежнасці ад памераў экспартуемых баз. Працы праводзілі дзве ночы: адна - для абнаўлення SMS, другая - для кластара.

Прастою трафіку не было, нягледзячы на ​​тое, што ўсе вышэйзгаданыя памылкі мы правяралі на сабе.

Вядома, часам могуць узнікнуць і зусім новыя цяжкасці ў працэсе абнаўлення, але гэта Check Point, і, як мы ўсе ведаем, заўсёды ёсць hotfix!

Удалых вам чорна-ружовых начэй і абнаўленняў!

Крыніца: habr.com

Дадаць каментар