Come implementare SAP HANA: esaminiamo i diversi metodi

SAP HANA è un popolare DBMS in-memory che include servizi di archiviazione (Data Warehouse) e analisi, middleware integrato, server applicativo e una piattaforma per la configurazione o lo sviluppo di nuove utility. Eliminando i ritardi dei tradizionali DBMS, SAP HANA può notevolmente aumentare le prestazioni dei sistemi, l'elaborazione delle transazioni (OLTP) e l'analisi aziendale (OLAP).

SAP HANA può essere implementata nelle modalità Appliance e TDI (parlando di ambienti di produzione). Ogni opzione ha i propri requisiti da parte del produttore. In questo post, parleremo dei vantaggi e degli svantaggi delle diverse opzioni, nonché, a titolo di esempio, dei nostri progetti reali con SAP HANA.

SAP HANA è composta da 3 componenti principali: host, istanza e sistema.

Host — è un server o un ambiente operativo per l'esecuzione del DBMS SAP HANA. I suoi componenti obbligatori includono CPU, RAM, storage, rete e sistema operativo. L'host fornisce collegamenti alle directory di installazione, dati, log o direttamente allo storage. Inoltre, lo storage per l'installazione di SAP HANA non deve necessariamente trovarsi sull'host. Se il sistema ha più host, sarà necessaria una memorizzazione centrale o una memorizzazione accessibile su richiesta da tutti gli host.

Istanze — è un insieme di componenti di sistema SAP HANA installati su un host. I componenti principali includono l'Index Server e il Name Server. Il primo, noto anche come "server di lavoro", elabora le richieste, gestisce le memorie dati attuali e i nuclei del database. Il Name Server memorizza informazioni sulla topologia dell'installazione SAP HANA, indicando dove operano i componenti e quali dati sono presenti su server.

Sistema – è una o più istanze con lo stesso numero. In sostanza, si tratta di un elemento separato che può essere acceso, spento o copiato (effettuare un backup). I dati vengono distribuiti nella memoria di diversi server che compongono il sistema SAP HANA.

Il sistema può essere configurato come mono-host (un'istanza su un host) o multi-host, distribuito (più istanze di SAP HANA distribuite su più host, con un'istanza per ogni host). Nelle configurazioni multi-host, ogni istanza deve avere lo stesso numero. Il sistema SAP HANA è identificato tramite il System ID (SID) – un numero unico composto da tre caratteri alfanumerici.

Virtualizzazione di SAP HANA

Una delle principali limitazioni di SAP HANA è il supporto per un solo sistema — un'unica istanza con un SID unico del server. Per un utilizzo più efficace delle risorse hardware o per ridurre il numero di server nel data center, è possibile utilizzare la virtualizzazione. In questo modo, altri paesaggi possono coesistere su un server con sistemi con minori requisiti (sistemi non produttivi). Per un server HA/DR di backup, la virtualizzazione può aumentare la velocità di switch tra macchine virtuali produttive e non produttive.

SAP HANA include il supporto per l'hypervisor VMWare ESX. Ciò significa che diversi sistemi SAP HANA – installazioni di SAP HANA con numeri SID differenti – possono coesistere su un unico host (server fisico comune) in diverse macchine virtuali. Ogni macchina virtuale deve operare su un sistema operativo supportato.

Per gli ambienti di produzione, la virtualizzazione di SAP HANA presenta seri limiti:

• l'eventuale scalabilità Scale-out non è supportata: la virtualizzazione può essere utilizzata solo con sistemi Scale-Up, sia essi BwoH/DM/SoH o 'pura' SoH;
• la virtualizzazione deve avvenire secondo le regole stabilite per i dispositivi Appliance o TDI;
• in disponibilità generale (GA) può esserci solo una macchina virtuale: le aziende che desiderano utilizzare la virtualizzazione con gli ambienti HANA di produzione devono partecipare al programma Controlled Availability con SAP.

Negli ambienti non produttivi, dove queste limitazioni non esistono, la virtualizzazione può essere impiegata per ottimizzare l'utilizzo delle risorse hardware.

Topologie SAP HANA

Passiamo a implementare SAP HANA. Qui sono definite due topologie.

• Scale-up – un grande server. Man mano che il database HANA cresce, anche il server cresce: aumenta il numero di CPU e la memoria. Nelle soluzioni con High Availability (HA) e Disaster Recovery (DR), i server di backup o di failover devono avere caratteristiche equivalenti ai server produttivi.
• Scale-out – l'intero volume del sistema SAP HANA è distribuito su più server identici. Il server Master contiene informazioni per l'Index Server e il Name Server. I server Slave non contengono questi dati, eccetto il server che assume le funzioni di Master in caso di guasto del server principale. I server di lavoro (Index Servers) gestiscono i segmenti di dati ad essi assegnati e rispondono alle richieste. I Name Server conoscono la distribuzione dei dati tra i server di lavoro. In caso di crescita di HANA, viene semplicemente aggiunto un altro nodo. In questa topologia è sufficiente avere un nodo di riserva per garantire la sicurezza dell'intero server. configurazione del server basta aggiungere un'altra nodo. In questa topologia è sufficiente avere un nodo di riserva per garantire la sicurezza dell'intero server.

Requisiti hardware di SAP

SAP ha requisiti obbligatori per l'hardware destinato a HANA. Questi riguardano gli ambienti produttivi; per i non-prod è sufficiente soddisfare requisiti minimi. Ecco quindi i requisiti per gli ambienti produttivi:

• CPU Intel Xeon v5 (SkyLake) / 8880/90/94 v4 (Broadwell)
• da 128 GB di RAM per applicazioni BW con 2 CPU, 256 GB con 4+ CPU;

Distribuiamo SAP HANA in modalità Appliance e TDI

Passiamo ora alla pratica e spieghiamo come implementare SAP HANA in modalità Appliance e TDI. Utilizzeremo le nostre piattaforme SAP HANA basate sui server BullSequana S e Bullion S, certificati da SAP per operare in queste modalità.

Piccola panoramica sui prodotti. BullSequana S basato su Intel Xeon Scalable include vari modelli, fino a 32 CPU in un singolo server. Il server è costruito su una struttura modulare, che garantisce scalabilità fino a 32 CPU e un numero equivalente di GPU. La memoria varia da 64 GB a 48 TB. Tra le caratteristiche di BullSequana S c'è il supporto per l'AI aziendale per prestazioni migliorate, accelerazione dell'analisi dei dati, potenziamento dei calcoli in memoria, e modernizzazione attraverso la virtualizzazione e tecnologie cloud.

Bullion S è dotato di CPU della famiglia Intel Xeon E7 v4. Il numero massimo di processori è 16. La RAM è scalabile da 128 GB a 24 TB. L'ampia gamma di funzionalità RAS garantisce un alto livello di disponibilità per infrastrutture critiche come SAP HANA. Bullion S è ideale per la consolidazione massiva dei data center, l'esecuzione di applicazioni in memoria, la migrazione di mainframe o sistemi legacy.

SAP HANA Appliance

L'Appliance è una soluzione preconfigurata che include server, storage e un pacchetto software per un'implementazione "chiavi in mano", con supporto centralizzato e un livello di prestazioni concordato. Qui HANA è fornita come hardware e software preconfigurati, completamente integrati e certificati. L'unità in modalità Appliance è pronta per l'installazione nel data center, e il sistema operativo, SAP HANA e (se necessario) un'ulteriore istanza di VMWare sono già configurati e installati.

La certificazione SAP definisce un livello garantito di prestazioni, così come il modello CPU, la quantità di RAM e lo storage. Dopo la certificazione, non è possibile modificare la configurazione senza perdere la garanzia. Per scalare la piattaforma HANA, SAP offre tre opzioni.

• Scale-Up BWoH/DM/SoH – scalabilità verticale, adatta per sistemi unici (un SID). L'aumento dei dispositivi Appliance avviene in incrementi di 256/384 GB, a partire dalla versione SAP HANA SPS 11. Questa proporzione mostra il massimo volume supportato da una singola CPU ed è comune a tutta la lista dei dispositivi Appliance certificati. Gli Appliance BWoH/DM/SoH con scalabilità verticale sono ottimali per le applicazioni BW on HANA (BWoH), Data Mart (DM) e le applicazioni SAP Suite on HANA (SoH).
• Scale-Up SoH è una versione semplificata del modello precedente, con meno limitazioni sulla quantità di RAM. Si tratta comunque di un server scalabile verticalmente, ma la massima capacità di RAM per 2 processori è ora di 1536 GB (fino alla versione SPS11) e 3 TB (SPS12+). Adatto solo per SoH.
• Scale-Out – è un'opzione con scalabilità orizzontale, un sistema che supporta configurazioni multi-server. La scalabilità orizzontale è ottimale per BW e – con alcune limitazioni – per SoH.

Nei server BullSequana S e Bullion S, la scalabilità verticale è la principale, poiché presenta meno limitazioni operative e richiede meno gestione. Per la modalità Appliance, c'è una più ampia gamma di dispositivi diversi.

Soluzioni BullSequana S per SAP HANA in modalità Appliance

*Opzionale E7-8890/94v4
Soluzioni Bullion S per SAP HANA in modalità Appliance

Tutte le soluzioni Bull in modalità Appliance sono certificate dalla versione SPS 12 di SAP HANA. L'hardware è installato in un rack standard da 19 pollici 42U, con due unità di alimentazione – PDU interne. I server certificati SAP includono:

• BullSequana S con Intel Xeon Skylake 8176, 8176M, 8180, 8180M (i processori con la lettera «M» supportano moduli di memoria da 128 GB). Le opzioni con Intel 8176 si presentano come le migliori in termini di rapporto qualità-prezzo.
• Bullion S con Intel Xeon E7-8880 v4, 8890 e 8894.

Lo storage SAN si collega direttamente al server tramite porte FC, quindi gli switch SAN non sono necessari. Possono però rivelarsi utili per l'accesso ai sistemi collegati a LAN o SAN.

Ecco un esempio di configurazione dello storage EMC Unity 450F nel nostro setup:

• Altezza: 5U (DPE 3U (25×2,5″ HDD/SSD) + DAE 2U (25×2,5″ HDD/SSD))
• Controller: 2
• Dischi: da 6 a 250 SAS SSD, da 600 GB a 15,36 TB ciascuno
• RAID: livello 5 (8+1), 4 gruppi RAID
• Interfaccia: 4 FC per controller, a 8 o 16 Gbit/s
• Software: Unisphere Block Suite

L'Appliance è un'opzione di distribuzione affidabile, ma ha uno svantaggio significativo: poca libertà nella configurazione dell'hardware. Inoltre, questa opzione potrebbe richiedere cambiamenti nei processi operativi della divisione IT.

SAP HANA TDI

Un'alternativa all'Appliance è la modalità TDI (Tailored Data center Integration), in cui è possibile selezionare specifici produttori e componenti infrastrutturali in base alle esigenze del cliente – considerando i compiti e il carico di lavoro. Ad esempio, il SAN può essere riutilizzato nel centro dati, riservando alcuni dischi per l'installazione di HANA.

Rispetto all'Appliance, nella modalità TDI l'utente ha molta più libertà nel soddisfare le esigenze. Questo semplifica notevolmente l'integrazione di HANA nel centro dati – è possibile costruire un'infrastruttura personalizzata. Ad esempio, si può variare il tipo e il numero di processori in base al carico.

Per calcolare le capacità, si raccomanda di utilizzare SAP Quick Sizer: uno strumento semplice che fornisce i requisiti di CPU e memoria per diverse tipologie di carico di lavoro in SAP HANA. Successivamente, per la pianificazione del paesaggio IT, è possibile contattare SAP Active Global Support. Dopodiché, il partner hardware di SAP HANA trasformerà i risultati dei calcoli in diverse possibili configurazioni di sistema, sia su hardware di fascia alta che su soluzioni più semplici. In modalità TDI per i server è consentito utilizzare CPU Intel E7, comprese Intel Broadwell E7 e Skylake-SP (Platinum, Gold, Silver con 8 o più core per processore), così come IBM Power8/9.

I server vengono forniti senza storage di rete, switch e rack, ma i requisiti hardware rimangono gli stessi della modalità Appliance: le stesse singole unità, soluzioni con scalabilità verticale o orizzontale. SAP richiede che siano utilizzati solo server, storage di rete e switch certificati, ma non è un problema: per la maggior parte dei produttori, praticamente tutto l'hardware è certificato.

Il controllo delle prestazioni deve essere effettuato utilizzando test HWCCT (Hardware Configuration Check Tool), che consentono di verificare il rispetto di specifici KPI SAP. Esiste inoltre un requisito non relativo all'hardware: HANA, il sistema operativo e l'hypervisor (opzionale) devono essere installati da professionisti certificati SAP.. Solo i sistemi che rispettano tutte le regole elencate possono ricevere supporto SAP relativo alle prestazioni.

La gamma di server BullSequana S in modalità TDI è simile alla gamma in modalità Appliance, ma senza sistemi di archiviazione, switch e armadi. Possono essere installati qualsiasi sistema di archiviazione dal catalogo certificato SAP — VNX, XtremIO, NetApp e altri. Ad esempio, se il VNX5400 soddisfa i requisiti di prestazione per SAP HANA, è possibile collegare il sistema di archiviazione Dell EMC Unity 450F come parte della configurazione TDI. Se necessario, vengono installati adattatori FC (1 o 10 Gbit/s) e switch Ethernet.

Ora, per darvi un'idea più chiara delle modalità descritte, vi racconteremo alcuni dei nostri casi reali.

Appliance + TDI: HANA per e-commerce

Il negozio online Mall.cz, parte del gruppo Mall, è stato fondato nel 2000. Ha filiali in Repubblica Ceca, Slovacchia, Polonia, Ungheria, Slovenia, Croazia e Romania. È il più grande negozio online del paese, vendendo fino a 75.000 prodotti al giorno, con un fatturato di circa 280 milioni di euro nel 2017.

L'aggiornamento dell'infrastruttura del centro dati era necessario a causa della migrazione a SAP HANA. La dimensione stimata era di 2×6 TB per l'ambiente di produzione e 6 TB per gli ambienti di test/sviluppo. Era necessaria una soluzione di disaster recovery per l'ambiente produttivo di SAP HANA in un cluster attivo-attivo.

Al momento dell'annuncio della gara, il cliente aveva un sistema SAP basato su server rack e blade standard. Due centri dati, situati a circa 10 km di distanza l'uno dall'altro, erano dotati di vari sistemi di storage – IBM SVC, HP e Dell. I sistemi chiave operavano in modalità di disaster recovery.

Inizialmente, il cliente aveva richiesto una soluzione certificata in modalità Appliance per SAP HANA per tutti i sistemi (ambienti di produzione e test/dev) con un'espansione fino a 12 TB. Tuttavia, a causa delle restrizioni di budget, si sono iniziate a considerare altre opzioni, come un numero maggiore di CPU con moduli di RAM di dimensioni inferiori (moduli da 64 GB invece di moduli da 128 GB). Inoltre, per ottimizzare il prezzo, era in discussione un sistema di archiviazione condiviso per gli ambienti di produzione e test/dev.

Si è deciso di optare per 4 CPU e 6 TB di RAM per l'ambiente di produzione, con possibilità di crescita. Per gli ambienti di test/dev in modalità TDI, si è scelto di utilizzare CPU meno costose: il risultato è stato di 8 CPU e 6 TB di RAM. A causa del numero maggiore di funzioni richieste dal cliente — replicazione, backup, ambienti di produzione e test/dev condivisi in una seconda sede — è stata utilizzata un'archiviazione DellEMC Unity in configurazione full-flash anziché dischi interni. Inoltre, il cliente ha richiesto una soluzione di disaster recovery basata sulla replicazione del sistema HANA (HSR) con un nodo quorum in una terza sede.

La configurazione finale per l'ambiente Prod consisteva in un server BullSequana S400 con Intel Xeon P8176M (28 core, 2.10 GHz, 165 W) e 6 TB di RAM. Lo storage è stato fornito da un'unità Unity 450F con 10x 3.84 TB. Per scopi di disaster recovery, sono stati utilizzati un BullSequana S400 con Intel Xeon P8176M (28 core, 2.10 GHz, 165 W) e 6 TB di RAM. Per l'ambiente test/dev è stato scelto un server BullSequana S800 con Intel Xeon P8153 (16 core, 2.00 GHz, 125 W) e 6 TB di RAM, oltre a uno storage Unity 450F con 15x 3.84 TB. Come quorum, i server applicativi (VxRail Solution) e la soluzione di backup (DataDomain) sono stati installati e configurati dai nostri specialisti.

L'attrezzatura è pronta per il futuro upgrade. Il cliente si aspetta una crescita dimensionale di HANA nel 2019 e dovrà solo installare i nuovi moduli nei rack.

Apparecchiatura: HANA per un grande integratore nel settore turistico.

Questa volta il nostro cliente è un importante fornitore di servizi IT, specializzato nello sviluppo di soluzioni tecnologiche per le aziende turistiche. Il cliente ha avviato un progetto ambizioso SAP HANA per implementare un nuovo sistema di fatturazione. Era necessaria una soluzione in modalità Appliance con 8 TB di RAM per gli ambienti Production e PreProd. In conformità con le raccomandazioni SAP, il cliente ha scelto l'opzione di scale-up verticale.

La sfida principale è stata l'implementazione di un'infrastruttura hardware basata su dispositivi certificati in modalità Appliance per SAP HANA. I criteri prioritari erano l'efficienza dei costi, l'elevata performance, la scalabilità e l'alta disponibilità dei dati.

Abbiamo proposto e realizzato una soluzione certificata da SAP, che include due server Bullion S16 per gli ambienti Prod e PreProd. L'hardware utilizza processori Intel Xeon E7-v4 8890 (24 core, 2,20 GHz, 165 W) ed è dotato di 16 TB di RAM. Per BW e ambienti Dev/Test abbiamo installato nove server Bullion S4 (22 core, 2,20 GHz, 150 W) con 4 TB di RAM ciascuno. Come storage è stata utilizzata una soluzione ibrida EMC Unity.

Questa soluzione supporta la scalabilità per tutti gli elementi del dispositivo, ad esempio fino a 16 socket con CPU Intel Xeon E7-v4. L'amministrazione in questa configurazione è semplificata, in particolare per la riconfigurazione o la suddivisione del server in partizioni.

Appliance + TDI: HANA per i metallurgisti

Il GMK «Nornickel» — uno dei maggiori produttori di nichel e palladio — ha deciso di aggiornare la propria piattaforma hardware SAP HANA per garantire il funzionamento di applicazioni e progetti aziendali critici. Era necessario ampliare l'esistente paesaggio in termini di capacità di calcolo. Una delle principali condizioni poste dal cliente era l'alta disponibilità della piattaforma, nonostante le limitazioni hardware.

Per gli ambienti produttivi abbiamo utilizzato il server Bullion S8 e lo storage in modalità SAP HANA Appliance. Per le piattaforme HA e test/dev, abbiamo implementato il sistema in modalità TDI. Abbiamo utilizzato un server Bull Bullion S8, due Bull Bullion S6 e uno storage ibrido. Questa combinazione ha consentito di aumentare significativamente la velocità delle applicazioni nel paesaggio SAP, incrementare la capacità di calcolo e le risorse di archiviazione, riducendo al contempo i costi operativi. È importante notare che il cliente ha mantenuto la possibilità di scalare fino a 16 CPU.

Vi invitiamo al Forum SAP

In questo post abbiamo esaminato il deployment di SAP HANA in vari modi, cercando di evidenziare i vantaggi e svantaggi delle opzioni disponibili. Se avete domande sull'implementazione di SAP HANA, saremo felici di rispondere nei commenti.

Invitiamo tutti coloro che sono interessati alle soluzioni Bull e alle possibilità di implementazione con SAP HANA al più grande evento SAP dell'anno: il 17 aprile a Mosca si terrà il SAP Forum 2019. Vi aspettiamo al nostro stand nella zona IoT: condivideremo molte informazioni interessanti e faremo anche molte estrazioni di premi.

Ci vediamo al forum!

Fonte: habr.com