SAP xostingini o'zgartirish tajribasi: tizimlarni og'riqli holda qanday ko'chirish kerak

SAP xostingini o'zgartirish tajribasi: tizimlarni og'riqli holda qanday ko'chirish kerak

Yoki bu mumkinmi? Albatta, SAP tizimlarini ko'chirish murakkab va mashaqqatli jarayon bo'lib, uning muvaffaqiyati barcha ishtirokchilarning yaxshi muvofiqlashtirilgan ishini talab qiladi. Va agar migratsiya qisqa vaqt ichida amalga oshirilsa, vazifa ancha murakkablashadi. Hamma ham buni qilishga qaror qilmaydi. Bir nechta sabablar bo'lishi mumkin. Masalan, jarayonning o'zi uzoq va tashkiliy jihatdan murakkab. Bundan tashqari, rejadan tashqari tizimning ishlamay qolishi xavfi mavjud. Yoki mijozlar bunday operatsiyani o'tkazib, sarflangan sa'y-harakatlarga mos keladigan foyda olishlariga ishonchlari komil emas. Biroq, istisnolar mavjud.

Kesish ostida biz mijozlar SAP tizimlarini ko'chirish va saqlash jarayonida duch keladigan qiyinchiliklar haqida gapiramiz, stereotiplar nima uchun har doim ham haqiqatga mos kelmasligini muhokama qilamiz va mijoz tizimlarini qanday qilib ko'chirishga muvaffaq bo'lganimiz haqidagi amaliy tadqiqot bilan o'rtoqlashamiz. uch oydan ko'proq vaqt ichida yangi infratuzilma.

SAP tizimlari hosting

Faqat besh yil oldin, mijozlar SAP ilovalari uchun xosting resurslaridan ommaviy ravishda foydalanishni boshlashlarini tasavvur qilish qiyin edi. Aksariyat hollarda ular o'z-o'zidan amalga oshirildi. Biroq, autsorsing modellari va bulutli xizmatlar bozorining rivojlanishi bilan mijozlarning dunyoqarashi o'zgara boshladi. SAP uchun bulut foydasiga tanlovga qanday argumentlar ta'sir qiladi?

  • SAP-ni joriy qilishni endigina rejalashtirgan yangi boshlanuvchilar uchun bulutli infratuzilma deyarli standart tanlovdir - resurslarning tizimning joriy ehtiyojlariga ko'lamliligi va resurslarni asosiy bo'lmagan vakolatlarni rivojlantirishga yo'naltirishni istamaslik.
  • Katta tizim landshaftiga ega bo'lgan kompaniyalarda SAP tizimlarini joylashtirish yordamida CIO'lar risklarni boshqarishning sifat jihatidan boshqa darajasiga erishadilar, chunki Hamkor SLA uchun javobgardir.
  • Uchinchi eng keng tarqalgan argument - yuqori mavjudlik va DR stsenariylarini amalga oshirish uchun infratuzilmani qurishning yuqori narxi.
  • Faktor 2027 - sotuvchi 2027 yilda eski tizimlarni qo'llab-quvvatlash tugashini e'lon qildi. Bu ma'lumotlar bazasini HANA-ga o'tkazishni anglatadi, bu modernizatsiya va yangi hisoblash quvvatini sotib olish uchun xarajatlarni talab qiladi.

Rossiyadagi SAP hosting bozori endi ancha etuk deb hisoblanishi mumkin. Bu esa o'z hosting platformalarini o'zgartirmoqchi bo'lgan mijozlar uchun keng imkoniyat yaratadi. Biroq, bunday loyihalar migratsiya tartib-qoidalarining murakkabligi tufayli haqli ravishda tadbirkorlar orasida tashvish tug'dirishi mumkin. Bu mijozlarni xizmat ko'rsatuvchi provayderlarga yuqori talablarni qo'yishga majbur qiladi, ular nafaqat SAP tizimlarini joylashtirish va ularga xizmat ko'rsatish bo'yicha alohida vakolatlarga, balki migratsiya sohasidagi muvaffaqiyatli tajribaga ham ega bo'lishi kerak.

SAP hostingni o'zgartirishda qanday qiyinchiliklar bor?

Hostinglar boshqacha. E'lon qilingan xizmat darajasiga nomuvofiqlik, kichik matndagi rezervasyonlar bilan ko'plab "lekin" va yulduzchalar, hosting provayderining cheklangan resurslari va imkoniyatlari, mijoz bilan aloqa qilishda moslashuvchanlikning yo'qligi, byurokratiya, texnik cheklovlar, texnik yordamning past malakasi. mutaxassislar, shuningdek, boshqa ko'plab nuanslar - bular mijozlar o'z biznes tizimlarini autsorsing infratuzilmasida ishlatishda duch kelishi mumkin bo'lgan tuzoqlarning kichik bir qismidir. Ko'pincha, mijoz uchun bularning barchasi soyada, ko'p sahifali shartnomaning o'rmonida qoladi va xizmatlardan foydalanish jarayonida paydo bo'ladi.

Bir nuqtada, mijozga u ko'rsatadigan xizmat darajasi uning kutganidan uzoq ekanligi ayon bo'ladi. Bu vaziyatni to'g'irlash uchun echimlarni topishning o'ziga xos katalizatoridir va muvaffaqiyatsizlikka uchragan taqdirda, muammolar chegaraga to'lib ketganda va u juda og'riqli bo'lsa, ular xizmat ko'rsatuvchi provayderni o'zgartirish yo'nalishi bo'yicha muqobil variantlarni ishlab chiqish uchun faol harakatlarga o'tadilar. .

Nega ular oxirgi daqiqagacha kutishadi? Sababi oddiy - mijozlar uchun tizimlarni ko'chirish jarayoni har doim ham shaffof va tushunarli emas. Migratsiya jarayoni bilan bog'liq haqiqiy xavflarni baholash mijoz uchun qiyin. Aytishimiz mumkinki, mijozlar uchun migratsiya o'ziga xos qora qutidir: bu noaniq, narx, tizimning ishlamay qolishi, xavflar va ularni qanday yumshatish mumkin, va umuman olganda, bu qorong'u va qo'rqinchli. Xuddi shunday, agar u ishlamasa, boshlar tepada ham, ijrochilarda ham aylanadi.

SAP - bu korxona darajasidagi tizim, murakkab va yumshoq qilib aytganda, arzon emas. Ularni amalga oshirish, o'zgartirish va texnik xizmat ko'rsatish uchun munosib byudjetlar sarflanadi va korxonaning hayoti ularning mavjudligi va to'g'ri ishlashiga bog'liq. Endi qandaydir yirik ishlab chiqarishni toβ€˜xtatish oqibatlarini tasavvur qiling. Bu ko'p sonli nolga ega bo'lgan raqamlarda hisoblanishi mumkin bo'lgan moliyaviy yo'qotishlar, shuningdek, obro'-e'tibor va boshqa teng darajada muhim xavflar.

Biz mijozlarimizdan birining SAP tizimlarini ko'chirishda har bir bosqichda yuzaga kelishi mumkin bo'lgan qiyinchiliklarni tahlil qilamiz.

Tayyorlash va dizayn

Migratsiya - bu juda ko'p turli qismlarga ega formula. Va eng muhimlaridan biri maqsadli (yangi) infratuzilmani loyihalash va tayyorlash bosqichidir.

Biz tizimlarning mavjud amaliyotiga, ularning arxitekturasiga sho'ng'ishimiz kerak edi. Maqsadli infratuzilmada biz mavjud echimlarni bir joyda takrorladik, ularni ba'zi nuqtalarda to'ldirdik va takomillashtirdik, ularni bir joyda qayta ko'rib chiqdik, xatolarga chidamlilik va mavjudlikni ta'minlash uchun echimlarni o'ylab ko'rdik va tanladik, shuningdek, iloji boricha barcha resurslarni birlashtirdik.

Dizayn jarayonida juda ko'p turli xil mashqlar bajarildi, bu oxir-oqibat migratsiyaga imkon qadar ko'proq tayyorgarlik ko'rish va har xil nuanslar va tuzoqlarni hisobga olish imkonini berdi (ular haqida keyinroq).

Biz maΚΌlumotlar markazimizga asoslangan individual tarzda ishlab chiqilgan xususiy bulutli infratuzilmaga erishdik:

  • SAP HANA uchun ajratilgan jismoniy serverlar;
  • Ilova serverlari va infratuzilma xizmatlari uchun VMware virtualizatsiya platformasi;
  • L2 VPN uchun ma'lumotlar markazlari o'rtasidagi takroriy aloqa kanallari;
  • mahsulotni va "qolgan hamma narsani" ajratish uchun ikkita asosiy saqlash tizimi;
  • Alohida server, disk javon va lenta kutubxonasi bilan Veritas Netbackup-ga asoslangan SRC.

SAP xostingini o'zgartirish tajribasi: tizimlarni og'riqli holda qanday ko'chirish kerak

Va bularning barchasini texnik nuqtai nazardan qanday amalga oshirdik.

SAP

  • Samarali HANA uchun saqlashdan samarali foydalanish uchun biz SAP yordamida tizimli ma'lumotlar bazasi replikatsiyasisiz umumiy disklardan foydalandik. Bularning barchasi yurak stimulyatori asosidagi Active-Standby SUSE HAE klasteriga o'ralgan edi. Ha, tiklash muddati replikatsiyaga qaraganda bir oz ko'proq, lekin biz saqlash joyini yarmiga tejaymiz va natijada mijozning byudjetini tejaymiz.
  • Ishlab chiqarishdan oldingi muhitda HANA klasterlaridan voz kechildi, ammo texnik jihatdan ishlab chiqarish konfiguratsiyasi takrorlandi.
  • Sinov va ishlab chiqish muhitlari MCOS konfiguratsiyasida klasterlarsiz yana bir nechta serverlarga tarqatildi.
  • Barcha dastur serverlari virtualizatsiya qilingan va VMware-da joylashtirilgan.

Seti

  • Biz boshqaruv va ishlab chiqarish tarmoqlarining konturlarini kalitlar to'plami bilan jismonan ajratdik, samaralilarini mijozning ma'lumotlar markazlariga aylantirdik.
  • Katta trafik oqimlarini aralashtirmaslik uchun biz etarli miqdordagi tarmoq interfeyslarini o'rnatdik.
  • Saqlash tizimlaridan ma'lumotlarni uzatish uchun biz klassik FC SAN zavodlarini yaratdik.

Saqlash

  • SAP ning samarali va ishlab chiqarishdan oldingi yuki all-flesh qatorida qoldirildi.
  • Ishlab chiquvchilar sinov muhiti va infratuzilma xizmatlari alohida gibrid massivga joylashtirildi.

IBS

  • Veritas Netbackup yordamida yaratilgan.
  • Biz MCOS konfiguratsiyalarini zaxiralash uchun o'rnatilgan skriptlarga biroz qo'shdik.
  • Tez tiklash uchun operativ nusxalarni disk javoniga joylashtiramiz va uzoq muddatli saqlash uchun lentalardan foydalanamiz.

Monitoring

  • Barcha apparat, OS va SAP Zabbix ostida o'rnatildi.
  • Biz Grafana-da ko'plab foydali asboblar panelini to'pladik.
  • Ogohlantirish paydo bo'lganda, Zabbix hodisalarni boshqarish tizimida so'rov yaratishi mumkin; biz uni Jira'da joriy qildik. Ma'lumotlar Telegram kanalida ham takrorlanadi.

Telegram

SAP xostingini o'zgartirish tajribasi: tizimlarni og'riqli holda qanday ko'chirish kerak

HANA ning umumiy salomatligi

SAP xostingini o'zgartirish tajribasi: tizimlarni og'riqli holda qanday ko'chirish kerak

SAP Application Server holati:

SAP xostingini o'zgartirish tajribasi: tizimlarni og'riqli holda qanday ko'chirish kerak

Infratuzilma xizmatlari

  • Ichki nom maydonlariga xizmat ko'rsatish uchun DNS-serverlar klasteri yaratildi, ular mijozning serverlari bilan sinxronlashtirildi.
  • Ma'lumotlar almashinuvi uchun alohida fayl serverini yaratdik.
  • Turli xil konfiguratsiyalarni saqlash uchun Gitlab qo'shildi.
  • Turli nozik ma'lumotlar uchun biz HashiCorp Vault-ni oldik.

Migratsiya jarayoni

Umuman olganda, migratsiya jarayoni quyidagi bosqichlardan iborat:

  • barcha kerakli loyiha hujjatlarini tayyorlash;
  • joriy provayder bilan muzokaralar - tashkiliy masalalarni hal qilish;
  • loyiha uchun yangi uskunalarni sotib olish, etkazib berish va o'rnatish;
  • test migratsiyasi va jarayonni tuzatish;
  • tizimlarni uzatish, migratsiyaga qarshi kurash.

2019-yil oktabr oyi oxirida biz shartnoma tuzdik, keyin arxitekturani loyihalashtirdik va buyurtmachi bilan kelishib, kerakli jihozlarga buyurtma berdik.

Siz birinchi navbatda e'tibor berishingiz kerak bo'lgan narsa - uskunani etkazib berish muddati. O'rtacha, dasturiy ta'minot ishlab chiqaruvchisining apparat platformalari uchun talablariga javob beradigan SAP NAHA uchun sertifikatlangan uskunani yetkazib berish 10-12 hafta davom etadi. Va mavsumiylikni hisobga olgan holda (loyihani amalga oshirish aynan Yangi yilga to'g'ri keldi), bu muddat yana bir oyga ko'payishi mumkin edi. Shunga ko'ra, jarayonni imkon qadar tezlashtirish kerak edi: biz distribyutor-yetkazib beruvchi bilan ishladik va samolyotda (quruqlik va dengiz yo'llari o'rniga) tez yetkazib berish haqida kelishib oldik.

Noyabr va dekabr oylari migratsiyaga tayyorgarlik ko'rish va jihozlarning bir qismini olish uchun sarflandi. Biz tayyorlanishni ommaviy bulutimizdagi sinov skameykasida amalga oshirdik, u erda barcha asosiy bosqichlarni bosib o'tdik va yuzaga kelishi mumkin bo'lgan qiyinchiliklar va muammolarni hal qildik:

  • loyiha jamoasi a'zolari o'rtasidagi o'zaro munosabatlarning batafsil rejasini daqiqama-daqiqa vaqtlari bilan tayyorladi;
  • ma'lumotlar bazasi va dastur serverlari uchun taxminan maqsadli infratuzilmada bo'lgani kabi sinov dastgohini qurdi;
  • integratsiyalarning ishlashini sinab ko'rish uchun zarur aloqa kanallari va infratuzilma xizmatlarini sozladi;
  • kesish stsenariylarini ishlab chiqdi;
  • Bulut, shuningdek, oldindan sozlangan virtual mashina shablonlarini yaratishga yordam berdi, biz ularni shunchaki import qildik va maqsadli landshaftga joylashtirdik.

Yangi yil bayramlari oldidan bizga uskunalarning birinchi partiyasi keldi. Bu ba'zi tizimlarni haqiqiy uskunada joylashtirish imkonini berdi. Hammasi kelmaganligi sababli, biz almashtirish uskunalarini uladik, ularni etkazib berishni sotuvchi va distribyutorlar bilan kelishib oldik. Biz yakuniy bosqichda maqsadli infratuzilma qoldiqlarini oldik.
Belgilangan muddatga erishish uchun muhandislarimiz Yangi yil bayramlarini qurbon qilishlari va bayramlar o'rtasida 2 yanvar kuni maqsadli infratuzilmani tayyorlash bo'yicha ishlarni boshlashlari kerak edi. Ha, bu ba'zida yonib ketganda sodir bo'ladi va boshqa variantlar yo'q. Korxonaning hayoti bog'liq bo'lgan tizimlarning ishlashi xavf ostida edi.

Migratsiyaning umumiy tartibi quyidagicha ko'rinish oldi: birinchi navbatda, eng kam tanqidiy tizimlar (rivojlanish landshafti, sinov landshafti), keyin ishlab chiqarish tizimlari. Migratsiyaning yakuniy bosqichi yanvar oyining oxiri va fevral oyining boshlarida sodir bo'ldi.

SAP xostingini o'zgartirish tajribasi: tizimlarni og'riqli holda qanday ko'chirish kerak

Migratsiya jarayoni daqiqagacha rejalashtirilgan edi. Bu barcha vazifalar ro'yxati, bajarish vaqti va mas'ul shaxslar ro'yxati bilan kesilgan rejadir. Sinov migratsiyasida barcha qadamlar allaqachon ishlab chiqilgan edi, shuning uchun jonli migratsiyada faqat rejaga rioya qilish va jarayonni muvofiqlashtirish kerak edi.

SAP xostingini o'zgartirish tajribasi: tizimlarni og'riqli holda qanday ko'chirish kerak

Migratsiya bir necha bosqichda tizimli ravishda amalga oshirildi. Har bir bosqichda ikkita tizim mavjud.

Uch oylik sprint natijasi CROC ma'lumotlar markazida to'liq ishlaydigan tizim bo'ldi. Umuman olganda, jamoaviy ish orqali ijobiy natijaga erishildi, jarayonda barcha ishtirokchilarning hissasi va fidoyiligi maksimal bo'ldi.

Loyihada mijozning roli

Mijozimiz ketayotgan provayder bilan muloqot qilish oson emas edi. Bu tushunarli, ular loyihani muvaffaqiyatli yakunlashdan manfaatdor bo'lganlar ro'yxatida oxirgi bo'lishdi. Xaridor barcha aloqa muammolarini kuchaytirish va pedallashtirish vazifasini o'z zimmasiga oldi va bu 100500% ni engdi. Buning uchun unga alohida rahmat. Jarayonda bunday mumkin bo'lgan ishtirokisiz, loyiha natijasi butunlay boshqacha bo'lishi mumkin edi.

Jarayonlarning "sobiq" provayder tomonida rasmiylashtirilishi tufayli infratuzilmani qo'llab-quvvatlash muammolardan tom ma'noda uzoq bo'lgan mutaxassislar tomonidan amalga oshirildi, o'sha paytda ham ularning mijozi. Misol uchun, bir xil ma'lumotlar bazasini eksport qilish jarayoni bir soatdan besh soatgacha davom etishi mumkin. Keyin bu qandaydir sehr-jodu, bizga hech qachon oshkor etilmagan sirdek tuyuldi. Ehtimol, texnik yordam muhandislari bu orada uzoq Rossiyada muddatlar borligini, yangi yil salatlarisiz muhandislar, mijoz yig'lab, azob chekayotganini unutib, meditatsiya bilan shug'ullanishgan ...

Loyiha natijalari

Migratsiyaning yakuniy bosqichi tizimlarni texnik xizmat ko'rsatishga o'tkazish edi.

Endi biz mijozlar so'rovlari uchun yagona oyna xizmatini taqdim etamiz va hamkorimiz - itelligence bilan birgalikda infratuzilma komponentlarini va SAP asoslarini qo'llab-quvvatlash bilan bog'liq barcha vazifalarni qamrab olamiz. Mijoz olti oydan beri shaxsiy bulutda yashaydi. Mana shu vaqt ichida xizmat koΚ»rsatish holatlari boΚ»yicha statistik maΚΌlumotlar:

  • 90 ta hodisa (20% mijoz ishtirokisiz hal qilingan)
  • SLA doirasida hal qilingan - 100%
  • Tizimni rejadan tashqari o'chirish - 0

Agar sizda bizning mijozimiz bilan bog'liq muammolar mavjud bo'lsa va ularni qanday hal qilish haqida ko'proq bilmoqchi bo'lsangiz, quyidagi manzilga yozing: [elektron pochta bilan himoyalangan]

Manba: www.habr.com

a Izoh qo'shish