VMware/Broadcom rischia di mandare in bancarotta gli operatori cloud europei: l'allarme del CISPE

[TheDarkAngel]

Originariamente inviato da !fazz

migri sap su 2 hypervisor diversi aggiornando il tuo sw e allineando il db giusto?

ma il dbms già gira e pure l'os corretto?

Per SAP l'importante è che la parte applicativa giri sullo stesso os, fintanto che il nuovo hypervisor supporta il tuo vecchio os, non c'è problema. In realtà puoi anche fare windows con release differenti e unix con release differenti. La restrzione forte è win su win, linux su linux, aix su aix, as400 su as400, hp-ux su hp-ux.

Il suo db è ancora a parte, può girare su os differenti e le restrizioni dipendono dal vendor di turno. Se prendiamo i db SAP anche qui basta che l'os sia il medesimo per garantire la sync.

L'esempio di HANA può girare su vmware + sles 12 e lo metti in sync con uno sles 15 su aws, tutto funzionerà senza problemi al giorno dello stacco.

E' l'os il mio layer di astrazione, l'hw è quasi completamente irrilevante, certo non puoi farmi powerpc big endian da una parte e x86-64 little endian dall'altra

[v10_star]

Originariamente inviato da TheDarkAngel

In genere queste migrazioni si fanno usando l'HA dei sistemi, parte dell'infrastruttura è presente in contemporanea su un virtualizzatore parte sull'altro ed al momento dello stacco, il disservizio è di pochi minuti sempre se presente.

Non ha molto senso migrare fisicamente l'as is, o si clona in sync o si sfrutta l'ha, nella mia esperienza di sistemista dt di ore sono presenti solo se il bugdet del cliente è ridotto, quando è per così dire "illimitato" il dt è sempre nell'ordine dei minuti.

Siamo d'accordo, ma occorre far digerire al cliente che ha pagato profumatamente la licenza vmware enterprise plus per avere l'ha, che ora deve cacciare fuori altri $ per avere l'ha/cluster a livello di os/servizio con tutto l'annesso e connesso: un esempio pratico, un DAG di Exchange.
Ripeto, per fortuna non ne ho più di queste situazioni da gestire...