BroadcomVMwareBig del Cloud
VMware/Broadcom rischia di mandare in bancarotta gli operatori cloud europei: l'allarme del CISPE
di Riccardo Robecchi pubblicata il 03 Aprile 2024, alle 16:51 nel canale CloudIl CISPE, consorzio che riunisce gli operatori di cloud europei, suona l'allarme: i nuovi termini di licenza di Broadcom/VMware rischiano di far finire in bancarotta molte realtà che non sono ritenute abbastanza grandi dal colosso americano
21 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoNon mancano certo i soldi, i cinesi hanno fatto infinitamente di più per la propria sovranità digitale pur avendo avuto per decenni un PIL più basso di quello europeo.
amen
in realtà se non erro Proxmox, forse la soluzione open piu matura, è tedesco come origine
certo andrebbe inserito nelle istituzioni
Noi abbiamo utilizzato "zerto" per migrare dall'on premise al cloud, sempre su piattaforma vmware.
Alla fine il disservizio è stato di poche ore (4), il tempo di fare l'ultima sync, spegnere le macchine per poi riaccenderle secondo una determinata logica in cloud.
eh grazie: vorrei vedere migrare a caldo da vmware a hyper-v, cambiando tutto l'hw virtuale, adattatori di rete, servizi di integrazione ecc ecc anche solo con un paio reboot
4 ore di disservizio: per te sembrano poche, per altre realtà anche con un quarto del tempo (anche di notte e nei we) avrei avuto gargantueschi uccelli per diabetici.
Ma grazie a dio non sono più nel b2b e non ho più a che fare con tutto il cinema delle licenze sp
si f0tta anche broadcom
4 ore di disservizio: per te sembrano poche, per altre realtà anche con un quarto del tempo (anche di notte e nei we) avrei avuto gargantueschi uccelli per diabetici.
Ma grazie a dio non sono più nel b2b e non ho più a che fare con tutto il cinema delle licenze sp
si f0tta anche broadcom
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.
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.
l'ha riesci a farla se hai un'infrastruttura omogenea ma se migri su un hypervisor molto diverso non riesci ad ottenerla anche perchè l'hw virtuale sarà diverso tra i vari sistemi
godo come un riccio
mi ricordo quando il mio ex datore di lavoro (uno dei più grandi distributori dell) mi voleva far fare le varie certificazioni vmware... mi licenziai... è un pessimo sistema vmware, che scompaia dalla faccia della terra! un miliardo di volte meglio kvm e anche proxmox è promettente. Poi oh se uno fa il cloud provider e non vede arrivare la tempesta... ma che scompaia pure lui!Dipende molto dal software, nel mio mondo, SAP, posso farlo senza problemi
Certo che non c'è una soluzione a tutto e serve tempo, pazienza e gente competente.
Certo che non c'è una soluzione a tutto e serve tempo, pazienza e gente competente.
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?
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
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".