#43 Al menos van 5 muertos por la peor catástrofe que ha ocurrido en España.
Que lo quieras aceptar es otra cosa.
Pero el asunto no va de muertos a pesar del uso partidista que la pseudo-izquierda española hace de ello.
La cuestión es que el coste del apagón va a ser brutal y eso tendrá consecuencias en las vidas de la gente.
Tardaremos en saberlo y eso no interesará a los medios afines, pero lo sabremos.
#133 Realmente #6 ha dado un argumento para que las eléctricas deberían estar en manos públicas. No puedes dejar algo tan importante para la estabilidad del país en alguien que "El día que se cabreen, y decidan parar la generación (y la inversión en la misma), o no operar el negocio de distribución" según sus propias palabras.
#33#9 Es como cuando vas a ver un museo palacio, a una casa señorial de algún noble que muy bonito, pero la realidad es que estás de visita y encima has tenido que pagar por la visita.
Pues cuando visitas un país de estos es lo mismo, muy bonito, pero ahí no vives y en cierta manera estás de visita porque no eres de allí.
Es como en el mismo bloque de pisos están los que viven en el ático con buenas vistas y están los que viven en el primero más sombrío y con vistas a la pared del bloque vecino, y sin embargo, ambos viven en la misma comunidad de vecinos, lo único que cambia es el número de puerta.
#9 Unos amigos acaban de regresar del Tirol, donde estuvieron varios años trabajando, sus hijos nacieron allí... El otro día estuvimos comentando esa escena.
#9 El franquismo fue bestial en el hacinamiento de Españoles en las grandes ciudades... mientras en europa prosperaban los barrios perifericos con casas-jardin bien comunicados con el centro, en España imperaba el pelotazo de bloques de pisos pequeños para hacinar al mayor numero de personas y concentradas en el menor numero de ciudades posibles... la emigracion del campo a la ciudad en aquella epoca fue bestial y ahora estamos pagando la España vaciada... de aquellos barros estos lodos...
4: No es compatible con los nodos de computo lxc ( este solo maneja nfs/ceph/local datastores)
En mi caso,
- El punto 1 no me duele
- Al punto 2 le buscaré un workaround para los pocos casos muy específicos que necesito (igual ni me hace falta si las máquinas stateless van por otro lado, a las malas las pocas que necesito así las puedo montar en otro datastore más lento)
- El punto 3 tengo que ver, espero que no sea bloqueante
- El punto 4 no me duele realmente, aunque ya puestos me gustaría poder tener contenedores vm-like más ligeros para cosas que no necesitaran virtualización completa, siempre puedo añadirlo a posteriori si veo que es interesante.
La otra opción que estaba mirando es usar una cabina que soporte Container Storage Interface (CSI) + kubevirt, pero una vez he visto lo de opennebula ni me planteo profundizar en ello.
«This is the recommended driver to be used when a high-end SAN is available. The same LUN can be exported to all the Hosts while Virtual Machines will be able to run directly from the SAN.»
Por lo que a priori puedes montar targets de una san en todos los hosts.
Inconvenientes:
1: No es proxmox, así que si te has decidido ya por proxmox y no quieres cambiar, no te vale.
2: Los discos y las vms no soportan snapshots
3: El despliegue de una nueva vm implica volcar por nfs/gluster/ssh la imagen inicial a un volumen lógico en la san (hasta que no monte el piloto no sabré cuan lento es el despliegue de vms)
La gracia es que en opennebula puedes usar diferentes datastores, en mi caso me planteo usar powerstore de dell/emc.
#69
Lo más similar entonces es ocfs2 y gfs2 que diría que no están abandonados ya que entre otras cosas están integrados en el kernel pero probablemente no te van a dar el mismo rendimiento que vmfs sobre todo por latencias.
Si que creo que si tienes una buena san y tiras de fc o rdma puedas superar a nfs en rendimiento con uno de los anteriores.
Hasta aquí las opciones que se me ocurren sin renunciar a nada.
Otra opción es que cada vm esté en su propio volume group y usar clvm para gestionar que máquina monta los vólumenes lógicos de cada volume group aunque esto probablemente tengas que cocinarlo tú mismo.
Si renuncias a live migration directamente o al menos a que estas sean rápidas y aceptas cierta cantidad de cocina propia, puedes crear un target por nodo de cómputo y jugar a montar el target en otro nodo si se cae el que lo tenga enchufado inicialmente.
Me repito (lo único nuevo que he dicho es lo de clvm) en general mi recomendación es:
1 : Monta pilotos y prueba, probablemente nfs no séa más que el último recurso.
2 : Contacta con Proxmox y le expones su caso al de ventas.
Otros filesystems distribuídos que me suenan, coda, gpfs, intermezzo... si diría que están bastante abandonados y otros que en su momento lo petaban lustre como que se han opacado con la llegada de ceph y si lo que quieres es enchufar directamente de la san a los nodos de cómputo cualquier cosa que implique meter cosas en medio queda descartada (lustre, ceph, pnfs, incluso nfs...)
#68 Entonces es como un GFS , Lustre o GlusterFS o si, OCFS2... hay un monton de FS de ese tipo.
Respecto a si es ideal o no, depende del uso. Si de lo que se trata es de ofrecer un disco para una VM no le veo la ventaja sobre por ejemplo LVM+iSCSI, o iSCSI a secas facilitando discos (que no espacio de almacenamiento)
#65 No si no se usan los dos discos al tiempo. No hay ningún problema. Conectar el target no supone acceso al disco (si se configura bien). Cuando la.maquina arranca en el nuevo nodo ya está parada en el anterior.
Llevo tiempo haciéndolo sin problemas
Proxmox soporta Ceph, que es similar a VMFS por lo que entiendo.
#64 vmfs es un filesystem en cluster si no me equivoco y como tal se compararía con cosas como ocfs2, gfs2 en incluso gluster y ceph dependiendo de como los montes.
ocfs2 diría que no tiene el mismo rendimiento que vmfs pero igual [ RDMA(infiniband) | fibra | nvme/tcp | iscsi ] + ocfs2 te cunde más que nfs a pelo, nfs a pelo no es precisamente lo que más rendimiento tiene.
En ese punto puedes plantearte que es lo más importante y según eso sacrificar una cosa u otra, por ejemplo puedes usar pvfs (si todavía se usa) si no te importa que se descarajen las vms si se cae un nodo.
pnfs no lo he tocado, me da en la nariz que también es frágil si se caen los nodos, pero ni idea de si se puede montar con redundancia, vamos para estas cosas yo no descartaría a priori que ceph + rados te vaya a dar un rendimiento menor a nfs a pelo sin probar antes.
Más allá de eso, puedes ver que sacrificas como decía antes, por ejemplo si tienes un target iscsi para cada nodo de cómputo, siempre puedes apuntar ese target a otro nodo si se cae el primero para rearrancar las vms y lo único que sacrificas ahí es por un lado la migración en vivo de las vms, que es más lenta y farragosa ya que sus discos se tienen que copiar por red a otro nodo, algo de disponibilidad, ya que si se cae un nodo igual no puedes arrancar todas las vms en otro nodo por capacidad y algo de operatividad ya que eso de apuntar targets a un nodo u otro es algo manual que tendrías que automatizar por tu cuenta.
Esto que te comento es por conocimiento general antes que por conocer las capacidades intrinsecas de proxmox, por ejemplo en este hilo he leído que proxmox usa corosync/pacemaker, por lo que a las malas podrias gestionar los target iscsi con un resource propio y tampoco me queda claro si proxmox permite la migración de vms de un nodo de cómputo a otro usando rsync/scp o algo así (opennebula lo permite).
El caso es que dependiendo de que quieras y necesites es probable que haya cosas mejores que nfs.
A favor de nfs está el que es relativamente sencillo, aunque eso se te complica igual si quieres que el servidor nfs no sea un punto único de fallo y ya depende de que tu cabina de discos tenga replica o de que lo montes con encima usando drbd (sincrono), zfs send / recv (asíncrono).
#58#59 Ceph distribuído es interesante y es por donde van los tiros al menos durante la última década.
En lo personal prefiero una SAN con replica a otra y meter multipath a ambas SAN (si están en local) sobre todo por rendimiento y porque son sólidas como una roca.
Lo que quiero descubrir es si puedo conseguir algo similar con hardware que en lugar de fibra use iscsi o nvm/tcp y si puedo meterle eso a diferentes nodos, haciendo que cada cual se preocupe de sus vms pero permitiendo migrarlas.
Me da a mí que no va a ser sencillo o incluso posible (a no ser que opennebula, proxmox o lo que sea que monte se integre con la gestión de los discos usando iscsi no creo que pueda exportar un volumen a todos los hosts y ya sin corromper los datos), pero ahora mismo, por pedir que no quede, a las malas siempre podemos terminar usando ceph o tirar de ocfs2 o incluso gfs2, dependiendo del rendimiento que me de cada cual.
#46 mi experiencia con intentar multipath en un entorno Proxmox (hará unos 4 o 5 años) no fue nada prometedora, la verdad, aunque, como dije en otro comentario, donde eso no era requisito se metió ZFS en cada nodo con replicación ente ellos y en algunos casos un "bind mount" del contenedor contra un fs en el nodo que lo alojaba, el cual estaba montado contra un servidor NFS, pero que conste que eso no es, ni de lejos, HA, pero sí lo que se necesitaba en esos proyectos.
Cc #38
#47#38#46 añado un punto que se me olvidó, si no lo han arreglado, si se caen dos nodos o más del clúster como se te pase por la cabeza reiniciar algún otro de los nodos ese ya no arrancaba por falta de quorom (hay un procedimiento para poder arrancarlo en estos casos, cosas del corosync), y eso era un punto en contra pero lo aceptaron pues tenían personal de IT en plantilla, sinó és una putada gorda.
#38#46 a ver, lo que no he mencionado és que por el medio había una denuncia de Siemens vía la BSA por tener Solid Edge pirata y eso llevó a un "registro judicial" (se presento la secretaria judicial, és un tema administrativo) y realizo una auditoría de todo el software de la empresa y posteriormente un juicio del cual no voy a entrar en detalles porqué tampoco los sé todos pero el resumen es que la empresa necesito pasarlo absolutamente todo a otros sistemas por tanto facilitó la implementación ya que no tenía que mantener compatibilidad con nada anterior, eso es un punto a favor, luego, en este caso (y otros que me vinieron a través de este cliente) con un clúster tenían suficiente, requerian poder mover entre nodos pero no "en caliente" y con el sisena de "storages" que lleva Proxmox era suficiente, eso junto a un sistema de replicacion de datasets ZFS entre los nodos fue suficiente para sus necesidades (en esas épocas Proxmox todavía no lo lleva "de serie" y lo implementamos nosotros, luego Proxmox ya lo metió también).
En otro sitio donde me encontré cabinas FiberChannel sí que no cambiaron el sistema ya que en esa época Proxmox (ni Linux) se acercaban ni de lejos a lo que permitía vmWare y se licenció el vSphere pero ese proyecto ya no lo realicé yo.
#38 Me apunto a la pregunta, últimamente estoy en una situación similar y creo que me está convenciendo open nebula a falta de montar una maqueta y probarlo con nodos kvm y puede que alguno lxcd.
Para el almacenamiento estoy a ver si pillo una cabina que pueda replicar en otra y meterle multipath, aunque aún no me queda claro de cuan factible sería. Como digo estoy en fase exploratoria y ver que montan los demás nunca es mala idea.
#13 hangla 
