La proprietà Oracle che puoi controllare



Il tuo ambiente Oracle funziona su tre “ore” che non controlli: Il rinnovo dell’hypervisor è arrivato con un costo più elevato per cui nessuno aveva preventivato. La finestra di supporto del database contiene una data. E da qualche parte, qualcuno ha affidato all’azienda l’AI che deve fare affidamento sui dati critici che risiedono in quei database. Ogni timeline appartiene a un vendor diverso ed è utilizzata per forzare una decisione sulla pianificazione di qualcun altro.

Il lavoro che Red Hat ed Everpure hanno svolto insieme esiste per rompere questo accoppiamento. Ogni livello della proprietà, ovvero hypervisor, Operating System (OS), storage e database stesso, deve modernizzarsi in base alla propria tempistica, che si controlla. Negli ultimi due anni, abbiamo costruito e pubblicato la convalida per renderla reale, nello specifico per i workload Oracle. In questo post vengono descritti i test, i risultati e il significato che hanno per il modo in cui sequenzi i prossimi tre anni.

Convalida dei workload Oracle su Red Hat OpenShift Virtualization ed Everpure

Il team di progettazione di Red Hat ha pubblicato un’architettura di riferimento completa per Oracle Database 19c su Red Hat OpenShift Virtualization, che copre le singole istanze e Oracle Real Application Clusters (RAC), con gli artefatti di test completi disponibili su GitHub. La convalida ha eseguito test di funzionalità, performance, scalabilità e migrazione in tempo reale. Lo storage sottoposto a questi test includeva Everpure™ FlashArray™ fornito tramite l’operatore Portworx® Enterprise.

I due risultati sono più importanti per chiunque pianifichi una migrazione:

  1. Migrazione in tempo reale di una macchina virtuale (VM) che esegue un database Oracle a istanza singola completata in media in 1-2 minuti e il risultato è stato se il database era inattivo o sotto carico di tipo produzione, con utenti virtuali che generano volumi costanti di transazioni simultanee. La migrazione dal vivo è l’operazione che rende vivibile una piattaforma di virtualizzazione. La manutenzione, il ribilanciamento e il refresh hardware dei nodi dipendono da essi e funzionano per Oracle su questa piattaforma nel modo che ti serve.
  2. La posizione di supporto è la stessa in cui operi già. Oracle certifica il OS all’interno della macchina virtuale, non l’hypervisor sottostante. Oracle Database su Red Hat Enterprise Linux (RHEL) rimane una configurazione del OS completamente supportata e Red Hat ha pubblicato architetture di riferimento complete e convalidate per l’esecuzione di questi workload, tra cui RAC, su OpenShift Virtualization. 

3 posizioni, 1 piattaforma

I clienti arrivano a questo lavoro da posizioni iniziali diverse. La piattaforma non li forza nello stesso percorso.

  • Mantenere la proprietà on-premise e uscire dalla piattaforma di virtualizzazione legacy. Questa è la posizione creata dalla lettera di rinnovo. Invece di essere vincolato a un rinnovo proibitivo dell’hypervisor, il toolkit di migrazione di Red Hat per la virtualizzazione sposta le macchine virtuali Oracle da VMware vSphere a OpenShift Virtualization senza che l’amministratore debba modificare l’host. L’ambiente dell’Database Administrator il lunedì è simile a quello del venerdì. FlashArray si trova sia sotto la vecchia piattaforma che sotto quella nuova, e ActiveCluster™ può spostare lo storage tra gli array senza rimuovere il database, il che significa che il livello di storage non blocca mai la finestra di migrazione. Il database non si è spostato. La piattaforma che la circonda.
  • Modernizzazione dell’orologio del database. Il ciclo di aggiornamento di Oracle è la sua funzione di forzatura e un aggiornamento eseguito male è il tipo di interruzione più costoso. Le snapshot degli array offrono cloni di produzione istantanei ed efficienti in termini di spazio per gli ambienti di sviluppo, test e performance, pertanto la prova viene eseguita rispetto ai dati reali senza una seconda copia della fattura di storage. FlashBlade® esegue il restore fino a 65TB all’ora, quindi il percorso di rollback viene misurato in pochi minuti anziché nel weekend. La migrazione della piattaforma e l’aggiornamento del database smettono di competere per la stessa finestra di modifica perché nessuno dei due dipende dall’altro.
  • Costruire intorno al database. I nuovi servizi ora arrivano come containers. La domanda è se si collocano sulla stessa piattaforma della proprietà o su una seconda con il proprio storage, backup e rotazione on-call. Everpure fornisce storage persistente sia alle macchine virtuali che ai containers da un unico piano, sugli stessi array. Il team che gestisce il patrimonio delle macchine virtuali e il team che spedisce servizi containerizzati smettono di gestire l’infrastruttura parallela. E gli eventuali workload AI, tra cui le funzionalità vettoriali e di recupero che arrivano nell’attuale generazione di database Oracle, ereditano lo stesso substrato invece di richiederne uno nuovo.

Valore del livello di storage

Una migrazione della piattaforma è una sequenza di momenti in cui i dati devono trovarsi in due posizioni, muoversi senza fermarsi o essere ripristinabili più velocemente rispetto agli avvisi aziendali. Queste sono proprietà di storage. I risultati della convalida di Red Hat su RAC hanno reso il punto empiricamente: Lo storage array di livello enterprise esterno ha sovraperformato le alternative iperconvergenti per le configurazioni più complesse. I punti di forza di una modernizzazione, tra hypervisor, tra versioni di database e tra macchine virtuali e container, sono esattamente dove la piattaforma di storage separa gli orologi o li ricollega.

L’architettura Evergreen® di Everpure estende la stessa logica allo storage stesso. L’array nell’ambiente Oracle viene aggiornato in modo non disruptive tra le generazioni di controller, eliminando i team di infrastruttura a un clock che tradizionalmente imponevano a tutti gli altri: il forklift refresh.

Cosa fare in questo senso

Inizia con la cucitura che riporta una data. Se si tratta di un rinnovo dell’hypervisor, esegui il toolkit di migrazione di Red Hat per la virtualizzazione rispetto a una macchina virtuale Oracle non di produzione e misura il risultato rispetto all’architettura di riferimento pubblicata. Se quella data è una finestra di supporto del database, crea l’ambiente di prova dalle snapshot questo trimestre e tempo il percorso di restore. Entrambi esercitano i giorni di costo e convertono una scadenza esterna in un piano misurato.

La proprietà che gestisci nel 2029 non sarà simile a quella che gestisci oggi. Il lavoro di cui sopra significa che puoi decidere l’ordine in cui cambia.

Per saperne di più, esplora queste risorse: