🥇Esperienza nel cambio di hosting SAP: come migrare i sistemi senza soffrire troppo

O è possibile? Certo, la migrazione dei sistemi SAP è un processo complesso e meticoloso, per il successo del quale è fondamentale la collaborazione di tutti i partecipanti. E se la migrazione avviene in tempi ristretti, il compito diventa MOLTO più difficile. Non tutti sono disposti ad affrontarlo. Le ragioni possono essere diverse. Ad esempio, il processo stesso è lungo e organizzativamente complesso. Inoltre, rischia di generare inattività non programmata dei sistemi. Oppure, i clienti non sono sicuri che, dopo aver affrontato un'operazione del genere, riceveranno benefici proporzionati agli sforzi investiti. Tuttavia, ci sono eccezioni.

Nel seguito parleremo delle difficoltà che i clienti affrontano durante il processo di migrazione e supporto dei sistemi SAP, discuteremo perché gli stereotipi non sempre corrispondono alla realtà e condivideremo un caso in cui siamo riusciti a migrare i sistemi di un cliente in una nuova infrastruttura in soli tre mesi e poco più.

Hosting dei sistemi SAP

Solo cinque anni fa era difficile immaginare che i clienti avrebbero iniziato a utilizzare su larga scala le risorse di hosting per le applicazioni SAP. 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à dei clienti ha cominciato a cambiare. Quali sono gli argomenti che influenzano la scelta a favore del cloud per SAP?

Per i neofiti che stanno appena pianificando di implementare SAP, l'infrastruttura cloud è praticamente la scelta standard: scalabilità delle risorse in base alle esigenze attuali del sistema e la volontà di non distogliere risorse dallo sviluppo di competenze non core.
Nelle aziende con un ampio panorama di sistemi, grazie all'hosting dei sistemi SAP, i CIO raggiungono un livello qualitativamente superiore nella gestione dei rischi, poiché per il SLA è responsabile il partner.
Il terzo degli argomenti più frequentemente affrontati è l'elevato costo di costruzione dell'infrastruttura per l'implementazione di scenari ad alta disponibilità e DR.
Fattore 2027: l'annuncio da parte del fornitore della cessazione del supporto per i sistemi obsoleti nel 2027. Questo significa migrare i database su HANA, il che comporta costi per la modernizzazione e l'acquisto di nuove capacità di calcolo.

Il mercato dell'hosting SAP in Russia può ora essere considerato abbastanza maturo. Questo offre ampie possibilità per i clienti che desiderano cambiare le loro piattaforme di hosting. Tuttavia, tali progetti possono giustamente suscitare preoccupazioni tra le aziende a causa della complessità della procedura di migrazione. Ciò costringe i clienti a presentare 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 di successo nel campo della migrazione.

Quali sono le difficoltà nel cambiare l'hosting SAP?

Esistono diversi tipi di hosting. La non corrispondenza con il livello di servizio dichiarato, i numerosi "ma" e le stelline con note a piè di pagina, la limitatezza delle risorse e delle possibilità fornitore di hosting, la mancanza di flessibilità nella comunicazione con il cliente, la burocrazia, le limitazioni tecniche, la scarsa competenza degli specialisti del supporto tecnico e molti altri dettagli — sono solo una piccola parte degli ostacoli che i clienti possono affrontare durante l'utilizzo dei loro sistemi aziendali in infrastrutture in outsourcing. Spesso, tutto questo rimane nell'ombra, nei meandri di contratti di molte pagine, e riemerge solo nell'uso dei servizi.

A un certo punto, diventa evidente per il cliente che il livello di servizio che sta ricevendo è lontano dalle sue aspettative. Questo funge da catalizzatore nella ricerca di soluzioni per rimediare alla situazione e, in caso di insuccesso, quando i problemi si accumulano fino a un limite insostenibile, si passa ad azioni attive per esplorare alternative in direzione del cambio di fornitore.

Perché si aspettano fino all'ultimo? La ragione è semplice: il processo di trasferimento dei sistemi non è sempre trasparente e comprensibile per i clienti. È difficile per un cliente valutare i reali rischi associati al processo di migrazione. Si può dire che la migrazione per i clienti è una sorta di scatola nera: non è chiaro quali siano i costi, il tempo di inattività dei sistemi, i rischi e come mitigarli; insomma, è tutto buio e spaventoso. Qui sta il punto: se non funziona, ci saranno conseguenze sia per i vertici che per gli esecutori.

SAP è un sistema a livello enterprise, complesso e, per dirla in modo sobrio, non economico. L'implementazione, la personalizzazione e il supporto richiedono budget considerevoli e la loro disponibilità e il corretto funzionamento dipendono dalla vitalità dell'azienda. Ora immaginate le conseguenze di un'interruzione in una grande produzione. Si tratta di perdite finanziarie che possono raggiungere cifre con un gran numero di zeri, così come rischi reputazionali e altri rischi non meno significativi.

Analizziamo le complessità che potrebbero sorgere in ciascuna fase utilizzando il caso della migrazione dei sistemi SAP di uno dei nostri clienti.

Preparazione e progettazione

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

Era necessario immergersi nell'implementazione esistente dei sistemi, nella loro architettura. Nell'infrastruttura target abbiamo ripetuto alcune delle soluzioni esistenti, integrato e migliorato in alcuni punti, e in altri abbiamo riprogettato, pensato e scelto soluzioni per garantire ridondanza e disponibilità, consolidando al massimo tutte le risorse.

Durante il processo di progettazione sono stati eseguiti molti esercizi diversi che alla fine hanno permesso di prepararci al meglio per la migrazione e di considerare tutte le possibili sfumature e ostacoli (di cui parleremo più avanti).

Ecco cosa abbiamo ottenuto: un'infrastruttura di 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 sistemi di archiviazione (SAS) principali per separare il produttivo dal 'resto';
un sistema di backup basato su Veritas Netbackup con un server dedicato, un'unità di archiviazione e una libreria a nastro.

Ecco come abbiamo realizzato tutto ciò dal punto di vista tecnico.

SAP

Per utilizzare efficacemente gli archivi per la produzione HANA, abbiamo utilizzato dischi condivisi senza replica del database tramite strumenti SAP. Il tutto è stato implementato in un cluster Active-Standby SUSE HAE basato su Pacemaker. Sì, il tempo di ripristino è un po' più lungo rispetto alla replica, ma otteniamo un risparmio dello spazio di archiviazione SCSI di due volte e, di conseguenza, un risparmio nel budget del cliente.
Nelle ambienti pre-produttivi si è rinunciato ai cluster HANA, ma tecnicamente è stata ripetuta la configurazione di produzione.
Gli ambienti di test e di 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

Sono stati fisicamente separati i contorni delle reti di gestione e delle reti di produzione con stack di switch, dirigendo le reti di produzione verso il data center del cliente.
È stato previsto un numero sufficiente di interfacce di rete per non mescolare grandi flussi di traffico.
Per il trasferimento dei dati dal sistema di archiviazione dei dati, sono state realizzate fabbriche FC SAN classiche.

Sistemi di archiviazione

Il carico produttivo e pre-produttivo di SAP è rimasto su un array all-flash.
Gli ambienti di test per gli sviluppatori e i servizi infrastrutturali sono stati collocati su un array ibrido separato.

SLT

È stato realizzato sulla base di Veritas Netbackup.
Sono stati aggiunti alcuni script incorporati per eseguire il backup delle configurazioni MCOS.
Le copie operative sono state collocate su un array di dischi per un rapido ripristino, mentre per la conservazione a lungo termine utilizziamo nastri.

Monitoraggio

Tutto l'hardware, il sistema operativo e SAP sono stati registrati in Zabbix.
Sono stati raccolti numerosi dashboard utili in Grafana.
In caso di allerta, Zabbix è in grado di aprire una richiesta nel sistema di gestione degli incidenti, che nel nostro caso è 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 la gestione degli spazi dei nomi interni è stato elevato un cluster di server DNS, che si sincronizza con i server del cliente.
È stato creato un server file separato per lo scambio di dati.
Per archiviare diverse configurazioni, è stato aggiunto Gitlab.
Per le varie informazioni sensibili è stato utilizzato HashiCorp Vault.

Processo di migrazione

In linea di massima, il processo di migrazione consiste nei seguenti passaggi:

preparazione della documentazione progettuale necessaria;
negoziazioni con l'attuale fornitore - risoluzione delle questioni organizzative;
acquisto, consegna e installazione della nuova attrezzatura per il progetto;
migrazione di prova e debug del processo;
trasferimento dei sistemi, migrazione in produzione.

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

La prima cosa a cui prestare attenzione sono i tempi di consegna delle attrezzature. In media, la consegna dell'hardware certificato per SAP NAHA, conforme ai requisiti del fornitore di software per le piattaforme hardware, richiede 10-12 settimane. E considerando la stagionalità (la realizzazione del progetto coincideva proprio con il Capodanno) questo termine potrebbe aumentare ulteriormente di un mese. Pertanto, è stato necessario accelerare al massimo il processo: abbiamo collaborato con il distributore-fornitore, concordando una consegna accelerata via aerea (invece di tramite strade terrestri e marittime).

Novembre e dicembre sono stati dedicati alla preparazione per la migrazione e all'acquisto di parte delle attrezzature. La preparazione è stata effettuata su un banco di prova nel nostro cloud pubblico, dove abbiamo messo a punto tutti i passaggi principali e identificato eventuali complessità e problemi:

abbiamo preparato un piano dettagliato per l'interazione dei membri dei team di progetto con tempistiche minute;
abbiamo costruito un banco di prova per il database e i server delle applicazioni in modo simile all'infrastruttura target;
abbiamo configurato i necessari canali di comunicazione e i servizi infrastrutturali per testare il funzionamento delle integrazioni;
abbiamo elaborato gli scenari di cutover;
il cloud ci ha anche aiutato a creare modelli preconfigurati di macchine virtuali, che successivamente abbiamo semplicemente importato e distribuito nell'architettura target.

Poco prima delle festività di Capodanno è arrivato il primo lotto di attrezzature. Questo ci ha permesso di avviare parte dei sistemi sull'hardware reale. Poiché non era arrivato tutto, abbiamo collegato l'attrezzatura di riserva, di cui eravamo riusciti a organizzare la consegna con il fornitore e i distributori. I restanti componenti dell'infrastruttura target li abbiamo ricevuti già nella fase finale.
Per rispettare le scadenze, i nostri ingegneri hanno dovuto sacrificare le vacanze natalizie e iniziare a lavorare sulla preparazione dell'infrastruttura target il 2 gennaio, proprio nel bel mezzo delle festività. Sì, a volte succede, quando c'è urgenza e non ci sono alternative. Era in gioco la funzionalità dei sistemi, su cui si basa l'attività dell'azienda.

L'ordine generale della migrazione è stato il seguente: in primo luogo i sistemi meno critici (paesaggio di sviluppo, paesaggio di test), poi i sistemi produttivi. La fase finale della migrazione si è svolta alla fine di gennaio-inizio febbraio.

Il processo di migrazione è stato dettagliato fino al minuto. Si tratta di un piano di cutover con un elenco di tutte le attività, i tempi di esecuzione e le persone responsabili. Tutti i passaggi erano già stati testati in una migrazione di prova, quindi nella migrazione reale era sufficiente seguire il piano e coordinare il processo.

La migrazione è stata effettuata per sistemi in diverse fasi. In ogni fase c'erano due sistemi.

Il risultato di un data sprint di tre mesi è stata una sistema completamente funzionante nel Data Center KROC. In generale, il risultato positivo è stato ottenuto grazie al lavoro di squadra, con il massimo contributo e impegno di tutti i partecipanti al processo.

Il ruolo del cliente nel progetto

Comunicare con il fornitore da cui il nostro cliente si allontanava non è stato facile. È comprensibile, erano gli ultimi nella lista delle persone interessate a un completamento di successo del progetto. Il cliente ha assunto le responsabilità per l'escalation e la gestione di tutte le comunicazioni e ha fatto un ottimo lavoro. A questo, un ringraziamento speciale. Senza tale partecipazione attiva, il risultato del progetto avrebbe potuto essere molto diverso.

A causa della formalità dei processi presso il 'vecchio' fornitore, la gestione dell'infrastruttura era affidata a specialisti completamente estranei ai problemi del cliente. Ad esempio, il processo di esportazione dello stesso database poteva richiedere da un'ora a cinque. A quel tempo, sembrava una sorta di magia, un segreto che non ci fu mai rivelato. Probabilmente gli ingegneri del supporto si dedicavano alla meditazione, dimenticando che, da qualche parte in quella lontana Russia, le scadenze incombevano, gli ingegneri erano senza insalate natalizie e il cliente piangeva e soffriva...

Risultati del progetto

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

Ora offriamo un servizio di sportello unico per le richieste del cliente e gestiamo l'intero volume di attività di supporto per i componenti dell'infrastruttura e SAP basis insieme al partner — itelligence. Il cliente vive in un cloud privato da sei mesi. Ecco le statistiche sui casi di servizio in questo periodo: