🥇 Esperienza nella migrazione degli hosting SAP: come trasferire i sistemi senza sofferenza

O è possibile? Certo, la migrazione dei sistemi SAP è un processo complesso e meticoloso, il cui successo dipende dal lavoro coordinato di tutti i partecipanti. E se la migrazione deve essere effettuata in tempi ristretti, la questione si complica ulteriormente. Non tutti sono disposti ad affrontarla. Le ragioni possono essere molteplici. Ad esempio, il processo è intrinsecamente lungo e organizzativamente complesso. Inoltre, c'è il rischio di inattività non pianificate dei sistemi. Oppure i clienti non sono certi di ricevere, dopo un'operazione del genere, benefici proporzionati agli sforzi spesi. Tuttavia, ci sono anche delle eccezioni.

Nel seguito parleremo delle difficoltà che i committenti affrontano durante la migrazione e la gestione dei sistemi SAP, discuteremo perché gli stereotipi non sempre corrispondono alla realtà e condivideremo un caso su come siamo riusciti a migrare i sistemi di un cliente nella nuova infrastruttura in soli tre mesi e poco più.

Hosting di sistemi SAP

Solo cinque anni fa era difficile immaginare che i clienti iniziassero a utilizzare risorse di hosting per le applicazioni SAP su larga scala. Nella maggior parte dei casi, venivano implementate on-premise. Tuttavia, con lo sviluppo dei modelli di outsourcing e del mercato dei servizi cloud, la mentalità degli acquirenti ha cominciato a cambiare. Quali sono gli argomenti che influenzano la scelta del cloud per SAP?

Per i neofiti che stanno pianificando l'implementazione di SAP, l'infrastruttura cloud è praticamente la scelta standard: scalabilità delle risorse in base alle attuali necessità del sistema e riluttanza a distogliere risorse dallo sviluppo delle competenze non core.
Nelle aziende con un ampio paesaggio sistemico, utilizzando l'hosting delle soluzioni SAP, i CIO raggiungono un livello qualitativo superiore nella gestione dei rischi, poiché il partner è responsabile per il SLA.
Il terzo dei motivi più comuni è l'alto costo della costruzione di un'infrastruttura per realizzare scenari di alta disponibilità e DR.
Il fattore 2027 è l'annuncio da parte del fornitore della cessazione del supporto per i sistemi obsoleti nel 2027. Ciò significa la migrazione del database su HANA, il che comporta costi per l'aggiornamento e l'acquisto di nuove capacità di calcolo.

Il mercato dell'hosting SAP in Russia può essere considerato abbastanza maturo. Ciò offre ampie opportunità per i clienti che desiderano cambiare le proprie piattaforme di hosting. Tuttavia, tali progetti possono legittimamente suscitare timori tra le imprese a causa della complessità della procedura di migrazione. Questo costringe i clienti a porre requisiti più elevati ai fornitori di servizi, che devono possedere non solo competenze eccezionali nell'hosting e nel supporto dei sistemi SAP, ma anche un'esperienza comprovata nel campo della migrazione.

Quali sono le difficoltà nel cambiare hosting SAP?

Esistono diversi tipi di hosting. La discrepanza rispetto al livello di servizio dichiarato, molte condizioni e stelle con riserve scritte in piccolo, limitazioni delle risorse e delle possibilità. fornitore di hosting, assenza di flessibilità nella comunicazione con il cliente, burocrazia, limitazioni tecniche, scarsa competenza del personale di supporto tecnico e molti altri aspetti — sono solo una parte delle insidie che i clienti possono affrontare durante l'utilizzo dei loro sistemi aziendali in infrastrutture esternalizzate. Spesso, per il cliente, tutto ciò rimane nell'ombra, nei meandri di un contratto di più pagine, e riemerge solo durante l'uso dei servizi.

A un certo punto, per il committente diventa chiaro che il livello di servizio che riceve è lontano dalle sue aspettative. Questo funge da catalizzatore nella ricerca di soluzioni per correggere la situazione e, in caso di insuccesso, quando i problemi si accumulano al limite e diventano davvero dolorosi, si passa ad azioni attive per esplorare alternative nel cambiamento del fornitore di servizi.

Perché si arriva all'ultimo momento? La ragione è semplice: il processo di migrazione dei sistemi per i clienti non è sempre trasparente e comprensibile. Al cliente risulta difficile valutare i reali rischi legati alla migrazione. Si potrebbe dire che la migrazione per i clienti è una sorta di scatola nera: non si capisce il costo, il tempo di inattività dei sistemi, i rischi e come mitigarli; insomma, è tutto oscuro e spaventoso. Qui la questione è che, se qualcosa va storto, le teste volano sia tra i dirigenti che tra gli esecutori.

SAP è un sistema di livello aziendale, complesso e, per certi versi, costoso. L'implementazione, la personalizzazione e la manutenzione richiedono budget considerevoli e la loro disponibilità e funzionamento corretto dipendono dalla vita dell'impresa. E ora immaginate le conseguenze dell'arresto di una grande produzione. Si tratta di perdite finanziarie che possono raggiungere cifre con molti zeri, oltre ai rischi reputazionali e altri rischi di uguale importanza.

Analizziamo le difficoltà che possono sorgere in ognuna delle fasi nel caso della migrazione dei sistemi SAP per uno dei nostri clienti.

Preparazione e progettazione

La migrazione è una formula con molteplici componenti. Uno degli aspetti più cruciali è la fase di progettazione e preparazione dell'infrastruttura target (nuova).

È stato necessario immergerci nella realizzazione attuale dei sistemi e nella loro architettura. Nella nuova infrastruttura, abbiamo riprodotto alcune soluzioni esistenti, in certi casi le abbiamo ampliate e migliorate, mentre in altri abbiamo riprogettato, riflettendo e selezionando soluzioni per garantire l'affidabilità e la disponibilità, oltre a consolidare al massimo tutte le risorse.

Durante la fase di progettazione, sono stati svolti vari esercizi che ci hanno permesso di prepararci al meglio per la migrazione, tenendo conto di tutte le possibili sfide e insidie (di cui parleremo più avanti).

Cosa abbiamo ottenuto alla fine: un'infrastruttura cloud privato progettata su misura, basata sul nostro data center:

server fisici dedicati per SAP HANA;
piattaforma di virtualizzazione VMware per server applicativi e servizi infrastrutturali;
canali di comunicazione ridondanti tra i data center per L2; VPN;
due storage SAN principali per separare il produttivo e "tutto il resto";
SRK basato su Veritas Netbackup con server dedicato, shelf di dischi e libreria a nastro.

Ecco come abbiamo implementato tutto questo dal punto di vista tecnico.

SAP

Per un utilizzo efficace degli storage per HANA in produzione, abbiamo utilizzato dischi condivisi senza replicazione del DB tramite le funzionalità di SAP. Tutto ciò è stato integrato in un cluster Active-Standby SUSE HAE basato su Pacemaker. Sì, i tempi di recupero sono leggermente più lunghi rispetto alla replicazione, ma in cambio otteniamo un risparmio di spazio nell'SAN di due volte e, di conseguenza, un risparmio sul budget del cliente.
Nelle ambienti pre-produttivi, abbiamo abbandonato i cluster HANA, ma abbiamo replicato tecnicamente la configurazione di produzione.
Gli ambienti di test e sviluppo sono stati distribuiti su diversi server senza cluster nella configurazione MCOS.
Tutti i server delle applicazioni sono stati virtualizzati e collocati in VMware.

Reti

Abbiamo fisicamente separato gli ambiti delle reti di gestione e delle reti produttive con stack di switch, disponendo le reti produttive verso il datacenter del cliente.
Abbiamo previsto un numero sufficiente di interfacce di rete per non mescolare grandi flussi di traffico.
Per il trasferimento dati dall'SAN abbiamo creato tradizionali fabbriche FC SAN.

Storage ibrido

Il carico produttivo e prepensionato di SAP è stato lasciato su un array all-flash.
Gli ambienti di test per gli sviluppatori e i servizi infrastrutturali sono stati posizionati su un array ibrido separato.

SRK

È stato realizzato utilizzando Veritas Netbackup.
Sono stati aggiunti alcuni script integrati per eseguire il backup delle configurazioni MCOS.
Le copie operative sono state collocate su una shelf di dischi per un rapido ripristino, mentre per lo storage a lungo termine utilizziamo nastri.

Monitoraggio

Tutto l'hardware, il sistema operativo e SAP sono stati integrati in Zabbix.
Abbiamo creato numerosi dashboard utili in Grafana.
In caso di allerta, Zabbix è in grado di aprire una richiesta nel sistema di gestione degli incidenti, che da noi è implementato su Jira. Inoltre, le informazioni vengono duplicate in un canale Telegram.

Stato generale di HANA

Stato del server delle applicazioni SAP:

Servizi infrastrutturali

Per gestire i namespace interni, è stato creato un cluster di server DNS che si sincronizza con i server del cliente.
È stato realizzato un server file dedicato per lo scambio di dati.
Per conservare diverse configurazioni, abbiamo aggiunto Gitlab.
Per diverse informazioni sensibili abbiamo scelto HashiCorp Vault.

Il processo di migrazione

In generale, il processo di migrazione consiste nei seguenti passaggi:

preparazione di tutta la documentazione di progetto necessaria;
negoziazioni con il fornitore attuale — risoluzione di questioni organizzative;
acquisto, consegna e installazione di nuove attrezzature per il progetto;
migrazione di prova e debug del processo;
trasferimento dei sistemi, migrazione operativa.

Alla fine di ottobre 2019 abbiamo firmato il contratto, poi abbiamo progettato l'architettura e dopo averla approvata con il cliente, abbiamo ordinato l'attrezzatura necessaria.

A cosa prestare attenzione in primo luogo — i tempi di consegna dell'attrezzatura. In media, la consegna di hardware certificato per SAP NAHA, conforme ai requisiti del produttore del software per le piattaforme hardware, richiede 10-12 settimane. E considerando la stagionalità (l'implementazione del progetto era proprio durante il nuovo anno) — questo periodo poteva allungarsi di un altro mese. Pertanto, era necessario accelerare al massimo il processo: abbiamo lavorato con il distributore-fornitore, concordando la consegna accelerata tramite aerei (invece di vie terrestri e marittime).

Novembre e dicembre sono stati dedicati alla preparazione per la migrazione e all'ottenimento di parte dell'attrezzatura. Abbiamo effettuato la preparazione su un ambiente di test nel nostro cloud pubblico, dove abbiamo eseguito tutti i passaggi principali e identificato possibili difficoltà e problemi:

abbiamo preparato un piano dettagliato di interazione per i membri dei team di progetto con le tempistiche minute per minuto;
abbiamo costruito un ambiente di test per i database e i server delle applicazioni in modo simile a quello dell'infrastruttura target;
abbiamo configurato i canali di comunicazione necessari e i servizi infrastrutturali per testare il funzionamento delle integrazioni;
abbiamo eseguito gli scenari di cutover;
il cloud ci ha anche aiutato a formare modelli preconfigurati di macchine virtuali, che successivamente abbiamo semplicemente importato e distribuito nel paesaggio target.

Poco prima delle festività di Capodanno, è arrivato il nostro primo lotto di attrezzature. Questo ci ha permesso di distribuire alcune sistemi su hardware reale. Poiché non era arrivato tutto, abbiamo collegato attrezzature sostitutive, di cui abbiamo potuto negoziare la fornitura con il fornitore e i distributori. I resti dell'infrastruttura target li abbiamo ricevuti già nella fase finale.
Per rispettare le scadenze, i nostri ingegneri hanno dovuto rinunciare alle vacanze di Capodanno e iniziare a lavorare per preparare l'infrastruttura richiesta il 2 gennaio, proprio nel pieno delle festività. Sì, a volte succede quando ci sono scadenze imminenti e non ci sono altre opzioni. Era in gioco il funzionamento dei sistemi che sostengono l'operatività dell'azienda.

L'iter complessivo di migrazione è stato il seguente: in primo luogo, i sistemi meno critici (paesaggio di sviluppo, paesaggio di test), poi i sistemi di produzione. La fase finale della migrazione si è svolta alla fine di gennaio e all'inizio di febbraio.

Il processo di migrazione era pianificato con precisione fino al minuto. Si trattava di un piano di cutover con un elenco di tutte le attività, tempi di esecuzione e persone responsabili. Tutti i passaggi erano già stati sperimentati in una migrazione di test, quindi nella migrazione effettiva era sufficiente seguire il piano e coordinare il processo.

La migrazione è stata eseguita per sistema in più fasi. In ogni fase sono stati coinvolti due sistemi.

Il risultato del trimestre di sprint è stata una soluzione completamente funzionante nel Data Center KROK. In generale, è stato ottenuto un risultato positivo grazie al lavoro di squadra, con il massimo impegno e dedizione da parte di tutti i partecipanti al processo.

Il ruolo del cliente nel progetto

Comunicare con il provider dal quale il nostro cliente si stava separando è stato complicato. Del resto, erano gli ultimi nella lista delle persone interessate al successo del progetto. Il cliente ha assunto compiti di escalation e gestione di tutte le questioni comunicative, riuscendo a portare a termine il compito al 100500%. Per questo gli va un ringraziamento speciale. Senza tale partecipazione attiva nel processo, il risultato del progetto sarebbe potuto essere completamente diverso.

A causa della formalizzazione dei processi da parte del "precedente" fornitore, la gestione dell'infrastruttura era affidata a specialisti che, in senso letterale, erano lontani dai problemi, al tempo ancora dei loro clienti. Ad esempio, il processo di esportazione dello stesso database poteva richiedere da un'ora a cinque. All'epoca sembrava che fosse una sorta di magia, un segreto che non ci fu mai rivelato. Probabilmente gli ingegneri del supporto tecnico, nel loro tempo libero, si dedicavano alla meditazione, dimenticando che da qualche parte, nella lontana Russia, ci sono scadenze, ingegneri senza insalate di Capodanno, un cliente che piange e soffre...

Risultati del progetto

L'atto finale della migrazione è stata la consegna dei sistemi in gestione.

Adesso offriamo un servizio di sportello unico per le richieste del cliente e gestiamo l'intero carico di lavoro per il supporto dei componenti infrastrutturali e di SAP basis insieme al nostro partner — itelligence. Il cliente vive nel cloud privato da sei mesi. Ecco alcune statistiche sui casi di servizio durante questo periodo: