Ці можна? Вядома, міграцыя SAP-сістэм - гэта складаны і карпатлівы працэс, для поспеху якога важна зладжаная праца ўсіх удзельнікаў. А калі міграцыя праводзіцца ў сціслыя тэрміны - задача шматкроць ускладняецца. Не ўсё рашаюцца на гэта. Прычын можа быць некалькі. Напрыклад, працэс сам па сабе працяглы і арганізацыйна складаны. Плюс ёсць рызыка незапланаваных прастояў сістэм. Або кліенты не ўпэўненыя, што, перажыўшы такую аперацыю, атрымаюць бенефіты, суразмерныя выдаткаваным намаганням. Аднак бываюць і выключэнні.
Пад катом раскажам аб цяжкасцях, з якімі сутыкаюцца заказчыкі ў працэсе міграцыі і суправаджэння SAP-сістэм, абмяркуем, чаму стэрэатыпы не заўсёды адпавядаюць рэальнасці, і падзелімся кейсам, як нам удалося міграваць сістэмы заказчыка ў новую інфраструктуру ўсяго за тры з невялікім месяцы.
Хостынг SAP-сістэм
Яшчэ нейкіх пяць гадоў таму складана было ўявіць, што кліенты масава пачнуць выкарыстоўваць хостынгавыя рэсурсы для SAP-прыкладанняў. У большасці выпадкаў іх укаранялі on-premise. Аднак з развіццём мадэляў аўтсорсінгу і рынку хмарных паслуг светапогляд заказчыкаў пачало мяняцца. Якія аргументы, якія ўплываюць на выбар на карысць аблокі для SAP?
- Для пачаткоўцаў, якія толькі запланавалі ўкараненне SAP, хмарная інфраструктура гэта практычна стандартны выбар - маштабаванасць рэсурсаў пад бягучую патрэбнасць сістэмы і нежаданне адцягваць рэсурсы на развіццё няпрофільных кампетэнцый.
- У кампаніях з вялікім сістэмным ландшафтам з дапамогай хостынгу SAP-сістэм CIO выходзяць на якасна іншы ўзровень кіравання рызыкамі, т.я. за SLA адказвае партнёр.
- Трэці з найбольш часта сустракаемых аргументаў - высокі кошт пабудовы інфраструктуры для рэалізацыі сцэнарыяў высокай даступнасці і DR.
- Фактар 2027 - анансаванае вендарам спыненне падтрымкі састарэлых сістэм у 2027 годзе. Гэта азначае перавод БД на HANA, што цягне за сабой выдаткі на мадэрнізацыю і закупку новых вылічальных магутнасцяў.
Рынак SAP-хостынгу ў Расіі цяпер можна лічыць дастаткова сталым. І гэта дае шырокія магчымасці для кліентаў, якія хочуць змяніць свае хостынг-платформы. Аднак такія праекты справядліва могуць выклікаць асцярогі ў бізнэсу з-за складанасці працэдуры міграцыі. Гэта змушае замоўцаў прад'яўляць падвышаныя патрабаванні да пастаўшчыкоў паслуг, якія павінны валодаць не толькі вылучнымі кампетэнцыямі па хостынгу і суправаджэнню сістэм SAP, але і паспяховым досведам у вобласці міграцыі.
У чым складаюцца складанасці змены SAP-хостынгу?
Хостынгі бываюць розныя. Неадпаведнасць заяўленаму ўзроўню сэрвісу, мноства "але" і зорачак з агаворкамі дробным тэкстам, абмежаванасць рэсурсаў і магчымасцяў хостынг-правайдэра, адсутнасць гнуткасці ў пытаннях камунікацыі з кліентам, бюракратыя, тэхнічныя абмежаванні, нізкая кампетэнтнасць спецыялістаў тэхнічнай падтрымкі, а таксама многія іншыя нюансы толькі малая частка падводных камянёў, з якімі могуць сутыкнуцца кліенты падчас эксплуатацый іх бізнэс-сістэм у аўтсорсінгавых інфраструктурах. Часцяком для кліента ўсё гэта застаецца ў цені, у нетрах шматстаронкавага кантракту, і ўсплывае ўжо падчас карыстання паслугамі.
У нейкі момант для замоўца становіцца відавочным, што ўзровень сэрвісу, які ён атрымлівае, далёкі ад яго чаканняў. Гэта з'яўляецца нейкім каталізатарам да пошуку рашэнняў па выпраўленні сітуацыі і ў выпадку няўдачы, калі праблемы назапашваюцца да мяжы і становіцца зусім балюча, пераходзяць да актыўных дзеянняў па прапрацоўцы альтэрнатыўных варыянтаў у напрамку змены пастаўшчыка паслугі.
Чаму цягнуць да апошняга? Прычына простая - працэс пераносу сістэм для кліентаў не заўсёды празрысты і зразумелы. Кліенту складана ацаніць сапраўдныя рызыкі, звязаныя з працэсам міграцыі. Можна сказаць, што міграцыя для кліентаў - гэта своеасаблівая чорная скрыня: незразумела, кошт, час прастою сістэм, рызыкі і як іх нівеліраваць, ды і наогул цёмна і страшна. Тут жа як, калі не атрымаецца, то галовы паляцяць і ў топаў, і ў выканаўцаў.
SAP - гэта сістэмы карпаратыўнага ўзроўню, складаныя і мякка кажучы не танныя. На іх укараненне, дапрацоўку, суправаджэнне марнуюцца прыстойныя бюджэты і ад іх даступнасці і карэктнай працы залежыць жыццядзейнасць прадпрыемства. А зараз прадстаўце наступствы прыпынку якой-небудзь буйной вытворчасці. Гэта фінансавыя страты, якія могуць вылічацца лічбамі з вялікай колькасцю нулёў, а таксама рэпутацыйнага і іншыя, не менш значныя рызыкі.
Разбярэм складанасці, якія могуць узнікнуць на кожным з этапаў на кейсе міграцыі SAP-сістэм аднаго з нашых заказчыкаў.
Падрыхтоўка і праектаванне
Міграцыя - гэта формула са мноствам розных складнікаў. І адным з найважнейшых з'яўляецца этап праектавання і падрыхтоўкі мэтавай (новай) інфраструктуры.
Нам неабходна было пагрузіцца ў існуючую рэалізацыю сістэм, іх архітэктуру. У мэтавай інфраструктуры мы недзе паўтарылі існуючыя рашэнні, у нейкіх момантах дапоўнілі і палепшылі, недзе перарабілі, прадумалі і выбралі рашэнні па забеспячэнні адмоваўстойлівасці і даступнасці, а таксама максімальна кансалідавалі ўсе рэсурсы.
У працэсе праектавання было выканана шмат розных практыкаванняў, якія ў выніку дазволілі максімальна падрыхтавацца да міграцыі і ўлічыць разнастайныя нюансы і падводныя камяні (пра іх пазней).
Што ў нас у выніку атрымалася - індывідуальна спраектаваная інфраструктура прыватнага аблокі на базе нашага ЦАД:
- выдзеленыя фізічныя серверы для SAP HANA;
- платформа віртуалізацыі VMware для сервераў дадаткаў і інфраструктурных сэрвісаў;
- дубляваныя каналы сувязі паміж ЦАД для L2 VPN;
- дзве асноўных СХД для падзелу прадуктыва і "ўсяго астатняга";
- СРК на базе Veritas Netbackup з асобным серверам, дыскавай паліцай і істужачнай бібліятэкай.
А вось як рэалізавалі ўсё гэта з тэхнічнага пункта погляду.
SAP
- Для эфектыўнага выкарыстання сховішчаў пад прадуктыўныя HANA выкарыстоўвалі агульныя дыскі без сістэмнай рэплікацыі БД сродкамі SAP. Усё гэта загарнулі ў Active-Standby кластар SUSE HAE на базе Pacemaker. Так, час аднаўлення крыху даўжэйшы, чым з рэплікацыяй, затое атрымліваем эканомію прасторы СГД у два разы і як следства эканомію бюджэту заказчыка.
- У прэпрадуктыўных асяроддзях ад кластараў HANA адмовіліся, але тэхнічна паўтарылі канфігурацыю прадуктыва.
- Тэставыя асяроддзі і асяроддзі распрацоўкі разнеслі яшчэ на некалькі сервераў без кластараў у канфігурацыі MCOS.
- Усе серверы прыкладанняў віртуалізавалі і размясцілі ў VMware.
сеткі
- Фізічна падзялілі контуры сетак кіравання і прадуктыўных сетак стэкамі камутатараў, загарнуўшы прадуктыўныя ў бок ЦАД замоўца.
- Заклалі дастатковую колькасць сеткавых інтэрфейсаў, каб не змешваць вялікія патокі трафіку.
- Для перадачы даных з СХД зрабілі класічныя FC SAN фабрыкі.
SHD
- Прадуктыўную і прэпрадуктыўную нагрузку SAP пакінулі на all-flash масіве.
- Тэставыя асяроддзі распрацоўшчыкаў і інфраструктурныя сэрвісы змясцілі на асобны гібрыдны масіў.
СРК
- Зрабілі на базе Veritas Netbackup.
- Трохі дапісалі ўбудаваныя скрыпты, каб бекапіць MCOS-канфігурацыі.
- Аператыўныя копіі паклалі на дыскавую паліцу, каб хутка аднавіцца, а для доўгатэрміновага захоўвання выкарыстоўваем стужкі.
Маніторынг
- Усё жалеза, АС і SAP завялі пад Zabbix.
- Сабралі мноства карысных дашбордаў у Grafana.
- Пры ўзнікненні алерта Zabbix умее заводзіць заяўку ў сістэме кіравання інцыдэнтамі, у нас яна рэалізавана на Jira. Таксама інфармацыя дублюецца ў Telegram-канал.
Тэлеграма
Агульны стан HANA
Стан сервера прыкладанняў SAP:
Інфраструктурныя сэрвісы
- Для абслугоўвання ўнутраных прастор імёнаў паднялі кластар DNS-сервераў, які сінхранізуецца з серверамі замоўца.
- Зрабілі асобны файлавы сервер для абмену дадзенымі.
- Каб захоўваць розныя канфігурацыі, дадалі Gitlab.
- Для рознай Sensitive-інфармацыі ўзялі HashiCorp Vault.
Працэс міграцыі
У агульным выпадку працэс міграцыі складаецца з наступных этапаў:
- падрыхтоўка ўсёй неабходнай праектнай дакументацыі;
- перамовы з бягучым правайдэрам - вырашэнне арганізацыйных пытанняў;
- закупка, дастаўка і ўстаноўка новага абсталявання пад праект;
- тэставая міграцыя і адладка працэсу;
- перанос сістэм, баявая міграцыя.
У канцы кастрычніка 2019 года мы падпісалі кантракт, далей спраектавалі архітэктуру, а пасля яе ўзгаднення з замоўцам замовілі неабходнае абсталяванне.
На што трэба звярнуць увагу ў першую чаргу - тэрміны пастаўкі абсталявання. У сярэднім пастаўка сертыфікаванага жалеза пад SAP NAHA, які адпавядае патрабаванням вытворцы ПА да апаратных платформаў, займае 10-12 тыдняў. А з улікам сезоннасці (рэалізацыя праекта выпадала акурат на новы год) - гэты тэрмін мог павялічыцца яшчэ на месяц. Адпаведна, патрабавалася максімальна паскорыць працэс: працавалі з дыстрыбутарам-пастаўшчыком, дамаўляліся аб паскоранай дастаўцы самалётамі (замест сухапутных і марскіх шляхоў).
Лістапад і снежань пайшлі на тое, каб выканаць падрыхтоўку да міграцыі і атрымаць частку абсталявання. Падрыхтоўку мы правялі на тэставым стэндзе ў нашым публічным воблаку, дзе адпрацавалі ўсе асноўныя крокі і адлавілі магчымыя складанасці і праблемы:
- падрыхтавалі дэталёвы план узаемадзеяння ўдзельнікаў праектных каманд з пахвіліннымі таймінгамі;
- пабудавалі тэставы стэнд для БД і сервераў прыкладанняў прыкладна гэтак жа, як у мэтавай інфраструктуры;
- настроілі неабходныя каналы сувязі і інфраструктурныя сэрвісы, каб праверыць працу інтэграцый;
- адпрацавалі cutover-сцэнары;
- воблака таксама дапамагло нам сфарміраваць наладжаныя шаблоны віртуальных машын, якія пасля мы проста імпартавалі і разгарнулі ў мэтавым ландшафце.
Незадоўга да навагодніх свят да нас прыехала першая партыя абсталявання. Гэта дазволіла разгарнуць частку сістэм на рэальным жалезе. Бо прыехала далёка не ўсё, мы падлучылі падменнае абсталяванне, аб пастаўцы якога нам атрымалася дамовіцца з вендарам і дыстрыбутарамі. Рэшткі мэтавай інфраструктуры мы атрымалі ўжо на фінальным этапе.
Каб паспець у тэрмін, нашым інжынерам прыйшлося ахвяраваць навагоднімі канікуламі і пачаць работу па падрыхтоўцы мэтавай інфраструктуры 2 студзеня, у самы разгар свят. Так, такое часам здараецца, калі гарыць і іншых варыянтаў проста няма. На коне была працаздольнасць сістэм, ад якіх залежыць жыццядзейнасць прадпрыемства.
Агульны парадак міграцыі выглядаў так: у першую чаргу - найменш крытычныя сістэмы (ландшафт распрацоўкі, ландшафт тэсціравання), затым - прадуктыўныя сістэмы. Фінальны этап міграцыі праходзіў у канцы студзеня - пачатку лютага.
Працэс міграцыі быў распісаны з дакладнасцю да хвіліны. Гэта cutover-план са спісам усіх задач, часам выканання і адказнымі асобамі. Усе крокі ўжо былі адпрацаваны на тэставай міграцыі, таму ў баявой міграцыі неабходна было проста прытрымлівацца плана і каардынаваць працэс.
Міграцыя праводзілася пасістэмна ў некалькі этапаў. У кожным этапе па дзве сістэмы.
Вынікам трохмесячнага спрынту стала сістэма, якая цалкам функцыянуе ў ЦАД КРОК. У цэлым станоўчы вынік атрыманы дзякуючы сумеснай рабоце, уклад і самааддача ўсіх удзельнікаў працэсу была максімальнай.
Роля заказчыка ў праекце
Камуніцыраваць з правайдэрам, якога пакідаў наш кліент, было няпроста. Яно і зразумела, яны былі апошнія ў спісе асобаў зацікаўленых у паспяховым завяршэнні праекта. Заказчык узяў на сябе задачы па эскалацыі і педаляванні ўсіх камунікацыйных пытанняў і справіўся з гэтым на 100500-XNUMX%. За гэта яму асобны дзякуй. Без такога пасільнага ўдзелу ў працэсе вынік праекта мог бы быць зусім іншым.
У сілу фармалізаванасці працэсаў на баку "былога" правайдэра суправаджэннем інфраструктуры займаліся спецыялісты, у прамым сэнсе далёкія ад праблем, на той момант яшчэ іх заказчыка. Напрыклад, працэс экспарту адной і той жа БД мог займаць ад гадзіны да пяці. Тады падавалася, што гэта нейкая магія, сакрэт які так нам і не адкрыўся. Мусіць інжынеры тэхпадтрымкі паміж справай аддаваліся медытацыі, забываючы аб тым, што дзесьці тамака ў далёкай Расеі дэдлайны, інжынеры без навагодніх салат, плача і пакутуе замовец…
Вынікі праекту
Фінальным акордам міграцыі была перадача сістэм на суправаджэнне.
Цяпер мы даем сэрвіс адзінага акна для зваротаў заказчыка і закрываем ўвесь аб'ём задач па суправаджэнні кампанент інфраструктуры і SAP basis разам з партнёрам – itelligence. Кліент жыве ў прыватным воблаку ўжо паўгода. Вось статыстыка па сэрвісных выпадках за гэты час:
- 90 інцыдэнтаў (20% вырашаны без прыцягнення заказчыка)
- Вырашаны ў рамках SLA - 100%
- Пазапланавых прыпынкаў сістэм - 0
Калі ў вас ёсць задачы, аналагічныя таму, што былі ў нашага кліента, і вы хочаце даведацца падрабязней, як іх вырашыць, пішыце: [электронная пошта абаронена]
Крыніца: habr.com