Oracle non está soportado sobre VMWare
FALSO. Oracle non certifica a súa base de datos sobre VMWare, e as solucións que da están orientadas ó SO nativo e non a nivel de virtualización. Oracle dará sempre asistencia ós seus produtos despregados sobre VMWare, sempre que se poida demostrar que non é un problema asociado á execución en VMWare.
Isto quere dicir que Oracle nun momento determinado podería non continuar na pesquisa nun SR se considera que debe ser escalado a VMWare, algo que a día de hoxe, aínda non me ocorreu, tendo chegado a xerar novos bug requests con incidencias sobre plataformas VMWare.
Si hai unha mención explícita a que non se admitirán SRs para BDs RAC en versión anterior á 11.2.0.2, pero descoñezo se esta condición se leva a cabo de xeito estrito. Até hoxe, e tras a apertura de numerosos casos sobre plataformas virtuais VMWare, nunca tiven notifica do peche ou non atención dun SR por empregar VMWare. En 2015, neste WhitePaper indica que até ese momento nunca recibiu unha incidencia relacionada coa BD Oracle na que vSphere fose o causante:
Para engadir un disco en quente en RAC debo apagar as VMs
FALSO. Engadir novos discos ASM é completamente posible sen parada de servidor de ningún tipo.
Cando usamos un datastore para crear os discos ASM, estamos a empregar un sistema de ficheiros VMFS que por defecto deshabilita o acceso de múltiples máquinas ós discos virtuais. A capa de almacenamento ASM é consciente da existencia dun clúster de almacenamento nunha configuración RAC e xestiona a concorrencia de acceso a través de múltiples nodos do clúster ós mesmos ficheiros, non dependendo de tecnoloxías de SO ou protocolo SCSI para a coordinación. Para este tipo de aplicacións “cluster-aware”, VMWare permite deshabilitar esta restrición, activando o flag multi-writer na configuración do disco.
Na versión ESXi 5.5 o bug VMWare 2078540 provocaba que o flag multi-writer se deshabilitase cando un disco se engade a unha máquina arrincada, fallando a adición de novos discos ASM e impedindo que estes se engadisen en quente. Este problema quedou solucionado na versión ESXi 5.5 P02 build -1892794, polo que versións posteriores non teñen esta limitación. En caso de estar nunha versión afectada por este bug, a solución de continxencia é efectivamente o apagado das máquinas antes de engadir o disco.
Se uso RAC sobre VMWare non poderei facer snapshots das VMs
FALSO. É habitual atopar clientes que sufren este problema, até o de agora na miña experiencia derivado dunha incorrecta configuración a nivel de VMWare. É certo que o emprego da opción multi-writer limita as accións que poden ser executadas sobre un disco, xa que impide por exemplo a suspensión da VM ou a ampliación de discos en quente. Podemos ver a táboa de funcionalidades con e sen soporte na web de VMWare.
Na miña opinión polas experiencias con administradores de sistemas e de VMWare, resulta confuso atopar na matriz que os snapshots non están soportados, o cal é certo, pero dende o punto de vista Oracle, o que nos interesa é ver que si se pode facer snapshots de VMs con discos independetes e persistentes, que si é posible dende vSphere 5.1u2. Se seguimos a documentación de VMWare Oracle Databases on VMware RAC Deployment Guide. Importante ter en conta esta será a configuración que terán os discos ASM, polo que un snapshot non incluirá eses discos, pero isto é algo que non nos importa xa que para a recuperación de Oracle en RAC contaremos con RMAN se o precisamos.
- Controladora Paravirtual independente dos discos de sistema (SO e software Oracle) para os discos compartidos (ASM).
- Thick Provision Eager Zeroed. O disco será xerado co seu tamaño real e enchido de valores cero. Trátase dun proceso de creación de disco mais lento que empregando outras opcións como thin provisioning.
- Multi-Writer.
- Independent se usamos VMFS (independent-persistent se usamos RDM).
Vemos estas configuracións en varias capturas do mencionado documento de RAC para VMWare:
Non podo usar Veeam Backup en máquinas VMWare con RAC
FALSO dende a versión 5.1 de vSphere. O motivo é similar ó do punto anterior. Debemos ter correctamente configuradas, controladoras e discos, tanto os de ASM como os de sistema. Con esta configuración, poderemos facer snapshots da VM quedando excluídos os discos ASM, pero a copia Veeam funcionará, dependendo de RMAN a recuperación da BD se esta fose precisa.
Se teño unha granxa VMWare teño que licenciar tódalas CPUs de tódolos nodos
MOI DISCUTIBLE. A nivel comercial e a nivel de auditoría, non hai dúbida, e Oracle esixirá o licenciamento de tódolos nodos dun clúster VMWare. Isto pode ser especialmente grave cando empregamos algunha das versións Standard, xa que Oracle pode reclamar o pago dunha licencia Enterprise pola limitación en número de sockets de Standard.
VMWare mantén vixente un documento denominado Understanding Oracle Certification, Support and Licensing for VMware Environments onde defende a posibilidade de licenciar un clúster Oracle de xeito parcial, empregando para elo regras DRS para limitar o movemento de máquinas virtuais, e manter un rexistro do movemento das máquinas virtuais entre nodos de cara a poder xustificar as CPUs concretas nas que o software Oracle foi executado. Esta proposta de VMWare foi respaldada no ano 2012 por Richard Garsthagen, Director de Desenvolvemento de Negocio Cloud de Oracle, provinte na etapa anterior de VMWare. En xaneiro de 2017, atopamos unha nova publicación de VMWare na que é moito mais clara a argumentación de licenciamento, facendo referencia explícita á configuración a empregar e ós condicionantes dos acordos de licenciamento de Oracle, especificamente no recollido no OLSA e no OMA. Neste documento, VMWare é contundente na afirmación de que é posible licenciar un subconxunto de servidores Oracle e cumprindo o acordo de licenciamento que o cliente debe asinar, simplemente mediante unha axeitada configuración de DRS, e co emprego da ferramenta VMWare LogInsight. Os logs de VMWare determinarán a cantidade de procesadores físicos empregados.
Oracle considera VMWare como unha tecnoloxía soft partitioning, onde a limitación de recursos que unha partición (máquina virtual neste caso), é feita a través de recurso de OS, entre eles a limitación das CPUs nas que o software é executado. Soft partitioning non é aceptado por Oracle para a limitación do número de CPUs. Tecnicamente, non temos a capacidade de diferenciar cal dos cores hardware estamos a empregar cando limitamos o número de vCPUs e unha MV pode ser executada en tódolos cores de xeito secuencia en diferentes momentos aínda que teña unha única vCPU. Non hai ningunha configuración VMWare que Oracle (a diferencia de Oracle VM) recoñeza para limitar o número de cores a licenciar.
Aceptando o anterior punto, que ocorre se dentro dun clúster nunca movo a miña máquina virtual? Podo deshabilitar vMotion e nunca arrincar unha MV nun nodo físico dun clúster VMWare. Nese caso, baixo que concepto é preciso licenciar un hardware no que nunca se chega a executar o software Oracle? A resposta é simplemente na previsión de que poida facelo. A argumentación de VMWare neste senso é mais razoable que a de Oracle, e é sintetizada na expresión “Galaxy Licensing” que implica a interpretación de Oracle dende o punto de vista das actuais funcionalidades VMWare, xa que vMotion non está restrinxido a día de hoxe a un vCenter como Oracle restrinxe.
Con Oracle VM podo restrinxir os cores a licenciar
CERTO. Oracle acepta a configuración de pinning de CPU en Oracle VM como tecnoloxía hard partitioning. Polo tanto, é posible licenciar só os cores ou sockets que están en uso por MVs usadas por Oracle.
Existe unha restrición con esta configuración, e é que Oracle non acepta para SE2 ningunha tecnoloxía hard partitioning, incluíndo a virtualización con OVM, se se empregan máquinas con mais de 2 sockets.