Oppure è possibile? Naturalmente, la migrazione dei sistemi SAP è un processo complesso e scrupoloso, il cui successo richiede il lavoro ben coordinato di tutti i partecipanti. E se la migrazione viene effettuata in breve tempo, il compito diventa molto più complicato. Non tutti decidono di farlo. Ci possono essere diverse ragioni. Ad esempio, il processo stesso è lungo e complesso dal punto di vista organizzativo. Inoltre esiste il rischio di tempi di inattività non pianificati del sistema. Oppure i clienti non sono sicuri che, dopo aver subito un'operazione del genere, riceveranno benefici commisurati agli sforzi profusi. Tuttavia, ci sono delle eccezioni.
Sotto il taglio parleremo delle difficoltà che i clienti affrontano nel processo di migrazione e manutenzione dei sistemi SAP, discuteremo perché gli stereotipi non sempre corrispondono alla realtà e condivideremo un case study su come siamo riusciti a migrare i sistemi di un cliente a un nuova infrastruttura in poco più di tre mesi.
Hosting di sistemi SAP
Solo cinque anni fa era difficile immaginare che i clienti avrebbero iniziato a utilizzare in modo massiccio le risorse di hosting per le applicazioni SAP. Nella maggior parte dei casi sono stati implementati on-premise. Tuttavia, con lo sviluppo dei modelli di outsourcing e del mercato dei servizi cloud, la visione del mondo dei clienti ha cominciato a cambiare. Quali sono gli argomenti che influenzano la scelta a favore del cloud per SAP?
- Per i principianti che hanno appena pianificato di implementare SAP, l'infrastruttura cloud è quasi una scelta standard: scalabilità delle risorse alle attuali esigenze del sistema e riluttanza a deviare risorse verso lo sviluppo di competenze non fondamentali.
- Nelle aziende con un ampio panorama di sistemi, con l'aiuto dell'hosting dei sistemi SAP, i CIO raggiungono un livello qualitativamente diverso di gestione del rischio, perché Il partner è responsabile dello SLA.
- Il terzo argomento più comune è il costo elevato della costruzione dell’infrastruttura per implementare scenari di alta disponibilità e DR.
- Fattore 2027: il fornitore ha annunciato la fine del supporto per i sistemi legacy nel 2027. Ciò significa trasferire la banca dati ad HANA, il che comporta costi per l’ammodernamento e l’acquisto di nuova potenza di calcolo.
Il mercato dell'hosting SAP in Russia può ormai essere considerato abbastanza maturo. E questo offre ampie opportunità ai clienti che desiderano cambiare la propria piattaforma di hosting. Tuttavia, tali progetti possono giustamente destare preoccupazione tra le imprese a causa della complessità della procedura di migrazione. Ciò costringe i clienti a porre maggiori richieste ai fornitori di servizi, che devono avere non solo competenze eccezionali nell'hosting e nella manutenzione dei sistemi SAP, ma anche esperienza di successo nel campo della migrazione.
Quali sono le difficoltà nel cambiare hosting SAP?
Gli hosting sono diversi. Incoerenza con il livello di servizio dichiarato, molti “ma” e asterischi con riserve in piccoli testi, risorse e capacità limitate del fornitore di hosting, mancanza di flessibilità in materia di comunicazione con il cliente, burocrazia, limitazioni tecniche, scarsa competenza del supporto tecnico specialisti, così come molte altre sfumature: queste sono solo una piccola parte delle insidie che i clienti possono incontrare quando gestiscono i loro sistemi aziendali in infrastrutture di outsourcing. Spesso per il cliente tutto questo resta nell'ombra, nella giungla di un contratto multipagina, ed emerge nel processo di fruizione dei servizi.
Ad un certo punto, diventa ovvio per il cliente che il livello di servizio che riceve è lontano dalle sue aspettative. Questo è una sorta di catalizzatore per trovare soluzioni per correggere la situazione e, in caso di fallimento, quando i problemi si accumulano al limite e diventa molto doloroso, si passa ad azioni attive per sviluppare opzioni alternative nella direzione di cambiare il fornitore di servizi .
Perché aspettano fino all'ultimo minuto? Il motivo è semplice: il processo di migrazione dei sistemi per i clienti non è sempre trasparente e comprensibile. È difficile per il cliente valutare i rischi effettivi associati al processo di migrazione. Possiamo dire che la migrazione per i clienti è una sorta di scatola nera: non è chiaro il prezzo, i tempi di inattività del sistema, i rischi e come mitigarli, e in generale è oscuro e spaventoso. È come se non funzionasse, le teste rotolerebbero sia ai vertici che agli artisti.
SAP è un sistema di livello aziendale, complesso e, per usare un eufemismo, non economico. Per la loro implementazione, modifica e manutenzione vengono spesi budget decenti e la vita dell'impresa dipende dalla loro disponibilità e dal corretto funzionamento. Ora immaginate le conseguenze dell’interruzione di una grande produzione. Si tratta di perdite finanziarie, che possono essere calcolate in cifre con un gran numero di zeri, nonché di rischi reputazionali e di altri rischi altrettanto significativi.
Analizzeremo le difficoltà che possono sorgere in ogni fase nel caso di migrazione dei sistemi SAP da un nostro cliente.
Preparazione e progettazione
La migrazione è una formula con molte parti diverse. E una delle più importanti è la fase di progettazione e preparazione della (nuova) infrastruttura target.
Avevamo bisogno di approfondire l'implementazione esistente dei sistemi e la loro architettura. Nell'infrastruttura di destinazione, abbiamo ripetuto le soluzioni esistenti da qualche parte, le abbiamo integrate e migliorate in alcuni punti, le abbiamo rifatte da qualche parte, abbiamo pensato e selezionato soluzioni per garantire tolleranza ai guasti e disponibilità e abbiamo anche consolidato tutte le risorse il più possibile.
Durante il processo di progettazione, sono stati eseguiti molti esercizi diversi, che alla fine hanno permesso di prepararsi il più possibile alla migrazione e di tenere conto di tutti i tipi di sfumature e insidie (ne parleremo più avanti).
Ciò che abbiamo ottenuto è un'infrastruttura cloud privata progettata individualmente basata sul nostro data center:
- server fisici dedicati per SAP HANA;
- Piattaforma di virtualizzazione VMware per server applicativi e servizi infrastrutturali;
- canali di comunicazione duplicati tra data center per VPN L2;
- due sistemi di stoccaggio principali per separare il prodotto e “tutto il resto”;
- SRC basato su Veritas Netbackup con server, scaffale dischi e libreria nastri separati.
Ed ecco come abbiamo implementato tutto questo dal punto di vista tecnico.
LINFA
- Per utilizzare in modo efficace lo storage per HANA produttivo, abbiamo utilizzato dischi condivisi senza replica sistemica del database utilizzando SAP. Tutto questo è stato racchiuso in un cluster SUSE HAE Active-Standby basato su Pacemaker. Sì, il tempo di ripristino è un po’ più lungo rispetto alla replica, ma risparmiamo la metà dello spazio di archiviazione e, di conseguenza, risparmiamo il budget del cliente.
- Negli ambienti di pre-produzione i cluster HANA venivano abbandonati, ma tecnicamente veniva ripetuta la configurazione di produzione.
- Gli ambienti di test e sviluppo sono stati distribuiti su molti più server senza cluster in una configurazione MCOS.
- Tutti i server applicativi sono stati virtualizzati e ospitati in VMware.
rete
- Abbiamo separato fisicamente i contorni delle reti di controllo e di produzione con pile di switch, indirizzando quelli produttivi verso i data center del cliente.
- Abbiamo installato un numero sufficiente di interfacce di rete per non mescolare grandi flussi di traffico.
- Per trasferire i dati dai sistemi di storage, abbiamo realizzato le classiche fabbriche SAN FC.
Magazzinaggio
- Il carico produttivo e pre-produttivo di SAP è stato lasciato sull'array all-flash.
- Gli ambienti di test e i servizi infrastrutturali degli sviluppatori sono stati posizionati su un array ibrido separato.
IBS
- Realizzato utilizzando Veritas Netbackup.
- Abbiamo aggiunto qualcosa agli script integrati per eseguire il backup delle configurazioni MCOS.
- Mettiamo le copie operative su uno scaffale del disco per un ripristino rapido e utilizziamo i nastri per l'archiviazione a lungo termine.
Monitoraggio
- Tutto l'hardware, il sistema operativo e SAP sono stati installati sotto Zabbix.
- Abbiamo raccolto molte dashboard utili in Grafana.
- Quando si verifica un avviso, Zabbix può creare una richiesta nel sistema di gestione degli incidenti; lo abbiamo implementato in Jira. Le informazioni sono duplicate anche nel canale Telegram.
Telegram
Salute generale dell'HANA
Stato del server dell'applicazione SAP:
Servizi infrastrutturali
- Per servire gli spazi dei nomi interni, è stato creato un cluster di server DNS, che è sincronizzato con i server del cliente.
- Abbiamo creato un file server separato per lo scambio di dati.
- Per memorizzare varie configurazioni, è stato aggiunto Gitlab.
- Per varie informazioni sensibili abbiamo utilizzato HashiCorp Vault.
Processo di migrazione
In generale, il processo di migrazione si compone delle seguenti fasi:
- preparazione di tutta la documentazione di progetto necessaria;
- trattative con l'attuale fornitore - risoluzione di problemi organizzativi;
- acquisto, consegna e installazione di nuove attrezzature per il progetto;
- test di migrazione e debug dei processi;
- trasferimento di sistemi, combattere la migrazione.
A fine ottobre 2019 abbiamo firmato un contratto, poi abbiamo progettato l’architettura e, dopo aver concordato con il cliente, abbiamo ordinato le attrezzature necessarie.
Ciò a cui devi prestare attenzione innanzitutto è il tempo di consegna dell'attrezzatura. In media, la consegna di hardware certificato per SAP NAHA che soddisfa i requisiti del produttore di software per le piattaforme hardware richiede 10-12 settimane. E tenendo conto della stagionalità (l'attuazione del progetto è caduta esattamente nel nuovo anno), questo periodo potrebbe aumentare di un altro mese. Di conseguenza, era necessario accelerare il più possibile il processo: abbiamo collaborato con il distributore-fornitore e abbiamo concordato una consegna rapida via aerea (invece che via terra e via mare).
Novembre e dicembre sono stati dedicati ai preparativi per la migrazione e alla ricezione di parte dell'attrezzatura. Abbiamo effettuato la preparazione su un banco di prova nel nostro cloud pubblico, dove abbiamo lavorato attraverso tutti i passaggi principali e individuato possibili difficoltà e problemi:
- preparato un piano dettagliato per l'interazione tra i membri del team di progetto con tempistiche minuto per minuto;
- costruito un banco di prova per il database e i server delle applicazioni più o meno allo stesso modo dell'infrastruttura di destinazione;
- configurato i canali di comunicazione e i servizi infrastrutturali necessari per testare il funzionamento delle integrazioni;
- scenari di transizione elaborati;
- Il cloud ci ha anche aiutato a creare modelli di macchine virtuali preconfigurati, che abbiamo poi semplicemente importato e distribuito nell'ambiente di destinazione.
Poco prima delle vacanze di Capodanno ci è arrivato il primo lotto di attrezzature. Ciò ha permesso di implementare alcuni sistemi su hardware reale. Poiché non tutto è arrivato, abbiamo collegato le apparecchiature sostitutive, la cui fornitura siamo riusciti a concordare con il venditore e i distributori. Abbiamo ricevuto i resti dell'infrastruttura target nella fase finale.
Per rispettare la scadenza, i nostri ingegneri hanno dovuto sacrificare le vacanze di Capodanno e iniziare i lavori di preparazione dell'infrastruttura prevista il 2 gennaio, nel pieno delle vacanze. Sì, questo a volte accade quando va a fuoco e semplicemente non ci sono altre opzioni. In gioco c’era la performance dei sistemi da cui dipende la vita dell’impresa.
L’ordine generale della migrazione era questo: prima i sistemi meno critici (panorama di sviluppo, panorama di test), poi i sistemi produttivi. La fase finale della migrazione ha avuto luogo tra la fine di gennaio e l'inizio di febbraio.
Il processo di migrazione è stato pianificato nei minimi dettagli. Questo è un piano di transizione con un elenco di tutte le attività, tempi di completamento e persone responsabili. Tutti i passaggi erano già stati elaborati nella migrazione di prova, quindi nella migrazione live è stato solo necessario seguire il piano e coordinare il processo.
La migrazione è stata effettuata sistematicamente in più fasi. Ci sono due sistemi in ogni fase.
Il risultato di uno sprint durato tre mesi è stato un sistema pienamente operativo nel data center CROC. In generale, attraverso il lavoro di squadra, è stato raggiunto un risultato positivo; il contributo e la dedizione di tutti i partecipanti al processo è stato massimo.
Il ruolo del cliente nel progetto
Comunicare con il fornitore che il nostro cliente stava lasciando non è stato facile. Ciò è comprensibile: erano gli ultimi nell'elenco delle persone interessate al completamento con successo del progetto. Il cliente si è assunto il compito di intensificare e risolvere tutti i problemi di comunicazione e ha affrontato questo problema al 100500%. Un ringraziamento speciale a lui per questo. Senza una tale fattibile partecipazione al processo, il risultato del progetto avrebbe potuto essere completamente diverso.
A causa della formalizzazione dei processi da parte del “ex” fornitore, il supporto dell'infrastruttura è stato effettuato da specialisti che erano letteralmente lontani dai problemi, a quel tempo ancora loro clienti. Ad esempio, il processo di esportazione dello stesso database potrebbe richiedere da un'ora a cinque. Allora sembrava che si trattasse di una sorta di magia, un segreto che non ci è mai stato rivelato. Probabilmente i tecnici dell'assistenza tecnica nel frattempo si sono abbandonati alla meditazione, dimenticando che da qualche parte nella lontana Russia ci sono delle scadenze, i tecnici senza l'insalata di Capodanno, il cliente piange e soffre...
Risultati del progetto
La fase finale della migrazione è stata il trasferimento dei sistemi per la manutenzione.
Ora forniamo un servizio a finestra unica per le richieste dei clienti e copriamo l'intero ambito delle attività relative ai componenti di supporto dell'infrastruttura e alla base SAP insieme al nostro partner - itelligence. Il cliente vive in un cloud privato da sei mesi. Ecco le statistiche sui casi di assistenza durante questo periodo:
- 90 incidenti (il 20% risolti senza coinvolgere il cliente)
- Risolto entro lo SLA – 100%
- Arresti di sistema non programmati – 0
Se hai problemi simili a quelli del nostro cliente, e vuoi saperne di più su come risolverli, scrivi a: [email protected]
Fonte: habr.com