Manejo-de-hosts-en-cielito.md

@@ -10,6 +10,30 @@ En las versiones más recientes de la IaC, crear un _host_, sea un contenedor LX
 
 La lógica de la IaC deducirá las IP del DNS y tiene valores por omisión para los diferentes parámetros de configuración, tanto [para contenedores](https://git.interior.edu.uy/adminsys/config/-/tree/main/group_vars/contenedores/) como [para virtuales](https://git.interior.edu.uy/adminsys/config/-/tree/main/group_vars/virtuales).
 
+# Criterios de elección de host
+
+Un contenedor LXC utiliza un espacio aislado en el mismo _kernel_ (núcleo linux) del servidor madre, mientras que una maquina virtual KVW/qemu emula una arquitectura de procesador en la que podrá correr otro _kernel_ (aunque, activando la virtualización por hardware en el servidor físico, la virtual puede hacer correr los pracesos virtualizados en uno de los _cores_ (núcleos de procesadores multi-threads)). Todas cuentas hechas, hay un sobrecosto computacional de una KVM sobre un contenedor LXC, lo que, por ende, preferiremos cuando es suficiente.
+
+También es importante considerar varios otros criterios, como las posibilidades de extensión de recursos, de respaldos, de migraciones, y de realizar _snapshots_[^1]
+
+Los hosts siempre son aprovisionados de un disco SSD en el servidor aplicativo, de decenas de Gb. Salvo pocas excepciones (como el correo electrónico), si requieren centenas de Gb, los discos correspondientes serán aprovisionados desde el storage NFS en el servidor redota.
+
+En un entorno PVE como el nuestro, con NFS se realiza [un storage de tipo file](https://pve.proxmox.com/wiki/Storage#_storage_types): los discos que se crean en un volumen del storage (`nubes`,`RespaldosStage`,...) serán archivon de formato `.raw` o `.qcow2`.
+
+`.raw` tiene dos desventajas: no permite _snapshots_, y ocupa siempre la totalidad del espacio afectado al volumen, mientras que `.qcow2` permite snapshots y ocupa sólo es espacio que efectivamente el volumen tiene ocupado por datos. 
+
+La limitante que tenemos que en los contenedores LXC sólo se pueden configurar discos NFS en formato `.raw`. Por ende:
+
+* si unas decenas de Gb de almacenamiento te alcanzan, los tendrás en alta disponibilidad SSD, desde un OS linux super optimizado en un contenedor,
+* si tus sistemas requieren centenas de Gb de almacenamiento, vamos por una KVM, con un mix de algo do discos SSD y almacenamiento más contundente, en un NL SAS en un storage SAN eth10Gb. Conviene diseñar bien tu particionamiento, par tener eventualmente índices y caches en SSD, y archivos masivos y secuenciales en el storage.
+
+Estos son los procesos de creación de hosts:
+
+* [Creación de un nuevo contenedor LXC](Creación-de-un-nuevo-contenedor-LXC)
+* [Creación de una nueva máquina virtual KVM](Creación-de-una-nueva-máquina-virtual-KVM)
+
+[^1]: un _snapshot_ es una imagen instantánea de un recurso - sea un disco duro, sea la memoria, sea todo un host - que define un estado al que se puede volver. A la diferencia de un respaldo, que es una copia completa de los datos (lo que lleva tiempo), un snapshot es instantateo, no es consistente de por sí, está asociado al recurso, con el que gestiona la diferencia que tiene, ocupando sólo el espacio correspondiente. Poder realizar _snapshots_ permite realizar respaldos consistentes de sistemas multi-usuarios complejos con un tiempo de detención mínimo de los servicios.
+
 # Colecciones y roles ansible utilizados
 
 Para la creación de hosts utilizamos [la colección `cielito.proxmox`](https://galaxy.ansible.com/ui/repo/published/cielito/proxmox/) y para la configuración de sistema [la colección `cielito.system`](https://galaxy.ansible.com/ui/repo/published/cielito/system/). Su documentación es referencia para las variables de configuración de hosts en _cielito_.