Mostrando las entradas con la etiqueta virtualizacion. Mostrar todas las entradas
Mostrando las entradas con la etiqueta virtualizacion. Mostrar todas las entradas

domingo, junio 16, 2024

LXC: Crear perfiles para limitar recursos de CPU y memoria

Traducción de la siguiente pagina 

Las instancias LXD se pueden limitar a la cantidad de recursos de CPU y memoria utilizados por el servidor host. Estos límites se pueden establecer en cada instancia individual o mediante el uso de perfiles. Esta guía práctica creará un perfil que establezca estos límites y luego lo aplicará a una instancia. Un solo perfil se puede reutilizar y aplicar a varias instancias.

Llamaremos al nuevo perfil cpu2-memory4, nombrándolo de una manera que identifique fácilmente su propósito. Configuraremos el perfil para limitar la instancia a 2 CPU virtuales y también a 4 GB de memoria. Para crear el nuevo perfil, ejecute el siguiente comando:

$ lxc profile create cpu2-memory4

Ahora tenemos un perfil vacío sin ninguna configuración. Para obtener una lista de los perfiles que tiene en su servidor LXD y ver el perfil cpu2-memory4 recién creado, ejecute el siguiente comando:

$ lxc profile list
+---------------+---------+
|    NOMBRE       | USADO POR |
+---------------+---------+
| default       | 2       |
+---------------+---------+
| cpu2-memory4  | 0       |
+---------------+---------+

El nuevo perfil ahora se puede modificar para limitar el uso de CPU y memoria. Podemos elegir editar el perfil directamente usando un editor (lxc profile edit cpu2-memory4) o establecer límites usando opciones de línea de comandos basadas en LXC.

Eligiendo la última opción, podemos establecer ambos límites de configuración al mismo tiempo con un solo comando. Establezcamos el límite de CPU a 2 CPU virtuales y el límite de memoria a 4GB de RAM ejecutando el siguiente comando:

$ lxc profile set cpu2-memory4 limits.cpu=2 limits.memory=4GB

Para ver el contenido del perfil use el siguiente comando:

$ lxc profile show cpu2-memory4
config:
  limits.cpu: "2"
  limits.memory: 4GB
description: ""
devices: {}
name: cpu2-memory4
used_by: []

Si está iniciando una nueva instancia, puede usar la opción –-profile (o -p) para agregar perfiles a la instancia a medida que se crea. Pero si la instancia ya existe, tendrá que agregar el nuevo perfil a la instancia. Supongamos que tenemos una instancia llamada vm1. Para agregar el perfil cpu2-memory4 a esta instancia, use el siguiente comando:

$ lxc profile add vm1 cpu2-memory4

Para mostrar la configuración aplicada a su instancia, use el siguiente comando:

$ lxc config show vm1 -e

La configuración del perfil se puede eliminar de la instancia. Para eliminar el perfil use el siguiente comando:

$ lxc profile remove vm1 cpu2-memory4

Cuando elimina el perfil de la instancia, el perfil aún existe y se puede usar para otras instancias. Si desea eliminar el perfil permanentemente, se puede eliminar con el siguiente comando:

$ lxc profile delete cpu2-memory4

LXC: Limitar recursos de memoria

En LXC al igual que con otras tecnologías de virtualización, es posible limitar la cantidad de memoria RAM que puede usar cada contenedor LXC. Esto puede ser útil para aislar aplicaciones con uso intensivo de memoria y evitar que un solo contenedor consuma todos los recursos disponibles del sistema.

Existen dos métodos principales para limitar la memoria RAM en LXC:

1. Utilizando el comando lxc config set

El comando lxc config set permite establecer diversas configuraciones para los contenedores LXC, incluida la cantidad de memoria RAM que pueden usar. La sintaxis para limitar la memoria RAM de un contenedor es la siguiente:

lxc config set <nombre_contenedor> limits.memory <valor_memoria>

Donde:

  • <nombre_contenedor> es el nombre del contenedor para el que desea establecer el límite de memoria RAM.
  • <valor_memoria> es la cantidad de memoria RAM que desea asignar al contenedor, especificada en bytes. Puede usar sufijos como M para megabytes o G para gigabytes.

Por ejemplo, para limitar la memoria RAM del contenedor nginx-proxy a 512 megabytes, ejecute el siguiente comando:

lxc config set nginx-proxy limits.memory 512M

2. Modificando el archivo de configuración del contenedor

Los contenedores LXC también pueden configurarse mediante archivos de configuración. Estos archivos contienen información sobre las características y recursos del contenedor. Para limitar la memoria RAM de un contenedor utilizando un archivo de configuración, siga estos pasos:

  1. Abra el archivo de configuración del contenedor que desea modificar. El archivo de configuración se encuentra generalmente en /var/lib/lxc/<nombre_contenedor>/config.
  2. Busque la línea que comienza con lxc.cgroup.memory.limit_in_bytes. Si esta línea no existe, agréguela al final del archivo.
  3. Establezca el valor de la línea lxc.cgroup.memory.limit_in_bytes a la cantidad de memoria RAM que desea asignar al contenedor, especificada en bytes. Puede usar sufijos como M para megabytes o G para gigabytes.
  4. Guarde el archivo de configuración.

Por ejemplo, para limitar la memoria RAM del contenedor nginx-proxy a 512 megabytes en el archivo de configuración, agregue la siguiente línea al final del archivo:

lxc.cgroup.memory.limit_in_bytes = 512M

Consideraciones adicionales

  • Es importante tener en cuenta que la cantidad de memoria RAM que asigna a un contenedor debe ser suficiente para que el contenedor funcione correctamente. Si asigna demasiada poca memoria RAM, el contenedor puede experimentar problemas de rendimiento o incluso fallar.
  • También es importante tener en cuenta que la memoria RAM asignada a un contenedor no es exclusiva. El contenedor aún puede acceder a la memoria RAM disponible en el sistema host, pero estará limitado por la cantidad que haya configurado.
  • Si necesita limitar aún más los recursos de un contenedor, puede utilizar otras opciones de configuración de LXC, como limits.cpu para limitar el uso de la CPU o limits.network para limitar el uso de la red.

Espero que esta información le sea útil. Si tiene alguna otra pregunta, no dude en preguntar.

LXC: limitar recursos de CPU

 

Traducción del siguiente articulo 

La administración de contenedores Linux (LXC) ahora se maneja a menudo con LXD, el proyecto principal de Canonical construido sobre LXC. LXD ofrece un conjunto de opciones para controlar los recursos de los contenedores Linux y establecer límites cuando sea apropiado. Esta publicación hablará sobre cómo establecer restricciones en la CPU, sin embargo, hay otras opciones disponibles para limitar casi cualquier tipo de recurso, como red, E/S de disco, memoria, etc.

Límites disponibles

La administración de la CPU se realiza de 1 de 4 maneras, según su carga de trabajo esperada y el régimen de administración de la CPU del host.

  • Número de CPU: define la cantidad de núcleos de CPU que LXC puede usar con este contenedor y distribuye automáticamente el tiempo de CPU entre los invitados cuando hay competencia por el tiempo de CPU. El valor utilizado es un número entero, por ejemplo 2.
  • Núcleos específicos: especifica núcleos físicos específicos para que los use el contenedor y distribuye el tiempo de CPU disponible entre contenedores cuando varios contenedores usan los mismos núcleos. El valor utilizado es un número entero o rango y puede estar separado por comas, por ejemplo 2, 0-1 o 0-1,3,5-9.
  • Participación limitada: permite un porcentaje específico de tiempo de CPU para el contenedor, o más si está disponible. Cuando el host no está bajo carga, un contenedor puede usar cualquier CPU disponible, pero cuando hay contención por la CPU, el contenedor se limitará a la cantidad especificada. El contenedor verá todos los núcleos de CPU del host (en TOP, por ejemplo).
  • Comparte de tiempo limitado: limitará el tiempo de CPU del contenedor a lo que se especifique de cada 200ms. Incluso si hay más CPU disponible, solo se permite lo que se especifica por porción de 200ms. El contenedor verá todos los núcleos de CPU del host (en TOP, por ejemplo).

Establecimiento de límites

El establecimiento de límites se realiza con el comando lxc. Luego hay dos opciones; limits.cpu para los puntos anteriores 1 y 2, o limit.cpu.allowance para los puntos 3 y 4.

lxc config set [CONTENEDOR] limits.cpu [VALOR]
  • [CONTENEDOR] es el nombre del contenedor; se puede obtener de lxc list si no está seguro.
  • [VALOR] es un valor válido del punto 1 o 2 anterior.

O

lxc config set [CONTENEDOR] limits.cpu.allowance [VALOR]
  • [CONTENEDOR] es el nombre del contenedor; se puede obtener de lxc list si no está seguro.
  • [VALOR] es un valor válido del punto 3 o 4 anterior.

Ejemplos de límite de CPU

  • Configure el contenedor nginx-proxy para que use cualquiera de las 2 CPU en el host.
lxc config set nginx-proxy limits.cpu 2
  • Configure el contenedor nginx-proxy para que use las CPU físicas 0, 3, 7, 8 y 9 en el host.
lxc config set nginx-proxy limits.cpu 0,3,7-9
  • Configure el contenedor nginx-proxy para que use el 20% de la CPU disponible en el host o más si está disponible.
lxc config set nginx-proxy limits.cpu.allowance 20%
  • Configure el contenedor nginx-proxy para que use no más del 50% de la CPU disponible en el host, o 100 ms por cada 200 ms de tiempo de CPU disponible.
lxc config set nginx-proxy limits.cpu.allowance 100ms/200ms

Puede ver /proc/cpuinfo para ver los núcleos disponibles en su contenedor, sin embargo, no incluirá ningún límite de programación o prioridad adicional.

cat /proc/cpuinfo | grep processor
processor: 0
processor: 1

Prioridad de CPU

La última opción relacionada con la limitación de CPU es la prioridad del tiempo de CPU. Esta opción solo se activa cuando el host está sobrecargado en recursos de CPU y los contenedores están luchando por el tiempo de CPU. Esto puede ocurrir en un solo núcleo (si se usan los puntos anteriores 1 o 2) o en todo el sistema (si no hay limitación de CPU en uso o si se usan los puntos anteriores 3 o 4).

Los valores disponibles van de 0 a 10 (inclusive). Los números más bajos significan una prioridad más baja, mientras que un número más alto significa que la máquina obtendrá tiempo de CPU antes que los números más bajos.

El siguiente comando establece una prioridad de CPU de 5 para el contenedor nginx-proxy:

lxc config set nginx-proxy limits.cpu.priority 5

El siguiente comando establece una prioridad de CPU de 2 para el contenedor php-backend, por lo que obtendría menos tiempo de CPU que el contenedor nginx-proxy cuando la CPU esté en contención.

lxc config set php-backend limits.cpu.priority 5 


Cómo instalar un cluster de MicroK8s en tres contenedores LXC, instalados en Ubuntu


Introducción

MicroK8s es una plataforma de Kubernetes simplificada que permite implementar y ejecutar aplicaciones en contenedores de forma fácil y rápida. En este artículo, se describe cómo instalar un cluster de MicroK8s en tres contenedores LXC, instalados en Ubuntu.

Requisitos previos

  • Una máquina con Ubuntu y LXC instalado
  • Conocimiento básico de Linux y contenedores LXC.

Pasos

1. Instalar LXC

En la máquina Ubuntu, instale el paquete LXC utilizando el siguiente comando:

sudo apt install lxc

 

2. Crear perfil microk8s

Debemos crear un perfil para que kubernetes se ejecute sin problemas en un contenedor LXC:

lxc profile create microk8s
# para ZFS
wget https://raw.githubusercontent.com/ubuntu/microk8s/master/tests/lxc/microk8s-zfs.profile -O microk8s.profile
# para ext4
wget https://raw.githubusercontent.com/ubuntu/microk8s/master/tests/lxc/microk8s.profile -O microk8s.profile
cat microk8s.profile | lxc profile edit microk8s
rm microk8s.profile  
 

2. Crear contenedor LXC base

Primero debemos crear un contenedor LXC utilizando utilizando el perfil microk8s, instalamos microk8s y después generamos una sanpshot de es:

lxc launch -p default -p microk8s ubuntu:22.04 microk8s01
#instalamos microk8s
lxc exec microk8s01 -- sudo snap install microk8s --classic  
#creamos el snapshot 
lxc snapshot microk8s01 microk8s-template

3. Crear los otros contenedores

En base a la snapshot creamos los otros dos contenedores:
#contenedor 2
lxc copy microk8s-template microk8s02
#contenedor 3
lxc copy microk8s-template microk8s03

4. Agregar nodos al cluster

Ya tenemos microk8s en tres maquinas, asi que ahora los uniremos entre ellos. Para eso desde el nodo microk8s01 ejecutaremos el siguiente comando:

root@microk8s01:~# microk8s add-node
From the node you wish to join to this cluster, run the following:
microk8s join 10.88.89.67:25000/da2fc5b4a60fc1e5fbbe703b007414c3/4523e5f8424e

Use the '--worker' flag to join a node as a worker not running the control plane, eg:
microk8s join 10.88.89.67:25000/da2fc5b4a60fc1e5fbbe703b007414c3/4523e5f8424e --worker

If the node you are adding is not reachable through the default interface you can use one of the following:
microk8s join 10.88.89.67:25000/da2fc5b4a60fc1e5fbbe703b007414c3/4523e5f8424e

 Donde <token> es el token de unión proporcionado por el primer nodo  y <apiserver-url> es la URL del servidor API de MicroK8s del primer nodo. Desde los demas nodos ejecutaremos el siguiente comando

microk8s join 10.88.89.67:25000/da2fc5b4a60fc1e5fbbe703b007414c3/4523e5f8424e


5. Verificar Cluster

Verifique que el cluster de MicroK8s esté funcionando correctamente utilizando el siguiente comando:

root@microk8s01:~# microk8s status 
microk8s is running
high-availability: yes
datastore master nodes: 10.88.89.67:19001 10.88.89.59:19001 10.88.89.165:19001
datastore standby nodes: none

root@microk8s01:~# microk8s kubectl get no
NAME STATUS ROLES AGE VERSION
microk8s01 Ready <none> 8m24s v1.29.4
microk8s02 Ready <none> 89s v1.29.4
microk8s03 Ready <none> 9s v1.29.4

Conclusión

Ha completado la instalación de un cluster de MicroK8s en tres contenedores LXC, instalados en Ubuntu. Ahora puede implementar y ejecutar aplicaciones en contenedores en su cluster de MicroK8s.

Recursos adicionales

domingo, septiembre 13, 2015

VRRP en Vyos/UBNT EdgeRouter

VRRP (Virtual Router Redundancy Protocol) es un protocolo de redundancia a nivel IP definido en el RFC3768. Fue diseña para permitir alta disponibilidad en la puerta de enlace por defecto en una subred, aunque se puede utilizar tambien para permitir alta disponibilidad de servicios (servidores web, Telefonía, etc). 
En este ejemplo revisaremos la funcionalidad original, alta disponibilidad de la puerta de enlace. Se presupone que ambos Vyos ya tienen acceso a internet, tienen configuradas interfaces, rutas, regla de NAT y de filtrado. El diagrama es el siguiente:


Los datos relevantes son:

Subred: 10.0.0./24
IP virtual: 10.0.0.10
IP router1: 10.0.0.11
IP router2: 10.0.0.12

El router1 sera el principal, tendrá mayor prioridad, y ademas tendra configurado el comando preempt que le permitira recuperar la IP virtual luego de una caida o reinicio.

Router1

set interfaces ethernet eth0 vrrp vrrp‐group 10
set interfaces ethernet eth0 vrrp vrrp‐group 10 virtual‐address 10.0.0.10/24
set interfaces ethernet eth0 vrrp vrrp‐group 10 preempt true
set interfaces ethernet eth0 vrrp vrrp‐group 10 priority 150
commit
save
#
show interfaces ethernet eth0 vrrp 
vrrp‐group 10 {
  preempt true
  priority 150
  virtual‐address 10.0.0.10/24
}
 

Router2


set interfaces ethernet eth0 vrrp vrrp‐group 10
set interfaces ethernet eth0 vrrp vrrp‐group 10 virtual‐address 10.0.0.10/24
set interfaces ethernet eth0 vrrp vrrp‐group 10 priority 100
commit
save
#
show interfaces ethernet eth0 vrrp 
vrrp‐group 10 {
  priority 100
  virtual‐address 10.0.0.10/24
}


Con esta configuración ya tendremos corriendo VRRP entre nuestro routers. Router1 en modo normal recibirá el trafico desde la subred, ante una caida de este Router2 obtendrá la IP virtual y permitira que el flujo de trafico a internet no se interrumpa.

Las opciones del comando VRRP en Vyos son las siguientes:

interfaces ethernet eth0 vrrp 
   vrrp-group <1-255> #VRRP group number
      advertise-interval <1-255> #Advertise interval (default 1)
      authentication
      description  #Description
      disable  #VRRP group disabled
      hello-source-address  #Source address for vrrp hello packets (optional)
      preempt  #Preempt mode
      preempt-delay <0-1000> #Preempt Delay in seconds
      priority <1-255> #Priority
      rfc3768-compatibility
      run-transition-scripts  #Scripts for VRRP state-transitions
      sync-group  #Add this vrrp group to a sync group
      virtual-address  #Virtual IP address (up to 20 per group)


sábado, agosto 01, 2015

L2TPV3 con Vyos/UBNT EdgeRouter/Vyatta



L2TPV3 es un estándar creado por la IETF que permite encapsular trafico de capa 2 y llevarlo sobre redes IP, la definición de Wikipedia es la siguiente:

"Layer 2 Tunneling Protocol Version 3 is an IETF standard related to L2TP that can be used as an alternative protocol to Multiprotocol Label Switching (MPLS) for encapsulation of multiprotocol Layer 2 communications traffic over IP networks. Like L2TP, L2TPv3 provides a pseudo-wire service, but scaled to fit carrier requirements."


Esta tecnologia se puede utilizar para compartir un segmento LAN entre dos sitios a traves de redes IP, Internet o una WAN privada.

Un ejemplo se ve en este diagrama:





 Aquí se uniran dos data center con virtualizacion, L2TPv3 permitirá migrar maquinas virtuales de un sitio a otro manteniendo la configuración de red de la misma.
  

La configuración es la siguiente:

Data Center Sitio 1

#Parámetros básicos de bridge 
set interfaces bridge br0 aging '300' 
set interfaces bridge br0 hello-time '2'
set interfaces bridge br0 max-age '20'
set interfaces bridge br0 priority '0'
set interfaces bridge br0 stp 'false'
# interface que conectara el Tunel 
set interfaces ethernet eth0 address 'x.x.x.x/24'
# Agregar interface de la LAN al bridge 
set interfaces ethernet eth1 bridge-group bridge 'br0'
# Configuración interface L2TPv3  
set interfaces l2tpv3 l2tpeth0 bridge-group bridge 'br0'
set interfaces l2tpv3 l2tpeth0 destination-port '10000'
set interfaces l2tpv3 l2tpeth0 encapsulation 'udp'
set interfaces l2tpv3 l2tpeth0 local-ip 'x.x.x.x'
set interfaces l2tpv3 l2tpeth0 peer-session-id '1'
set interfaces l2tpv3 l2tpeth0 peer-tunnel-id '1'
set interfaces l2tpv3 l2tpeth0 remote-ip 'y.y.y.y'
set interfaces l2tpv3 l2tpeth0 session-id '1'
set interfaces l2tpv3 l2tpeth0 source-port '10000'
set interfaces l2tpv3 l2tpeth0 tunnel-id '1' 
 
 
Data Center Sitio 2
 
#Parámetros básicos de bridge 
set interfaces bridge br0 aging '300'
set interfaces bridge br0 hello-time '2'
set interfaces bridge br0 max-age '20'
set interfaces bridge br0 priority '0'
set interfaces bridge br0 stp 'false'
# interface que conectara el Tunel 
set interfaces ethernet eth0 address 'y.y.y.y/24'
# Agregar interface de la LAN al bridge 
set interfaces ethernet eth1 bridge-group bridge 'br0' 
# Configuración interface L2TPv3  
set interfaces l2tpv3 l2tpeth0 bridge-group bridge 'br0'
set interfaces l2tpv3 l2tpeth0 destination-port '10000'
set interfaces l2tpv3 l2tpeth0 encapsulation 'udp'
set interfaces l2tpv3 l2tpeth0 local-ip 'y.y.y.y'
set interfaces l2tpv3 l2tpeth0 peer-session-id '1'
set interfaces l2tpv3 l2tpeth0 peer-tunnel-id '1'
set interfaces l2tpv3 l2tpeth0 remote-ip 'x.x.x.x'
set interfaces l2tpv3 l2tpeth0 session-id '1'
set interfaces l2tpv3 l2tpeth0 source-port '10000'
set interfaces l2tpv3 l2tpeth0 tunnel-id '1'

miércoles, mayo 28, 2008

Netkit: Virtualizacion de red para los pobres

Hola de nuevo, ahora tocare un tema mas especifico, el cual es la virtulizacion de sistemas operativos, este se refiera a la posibilidad de correr una parte o todo un sistema operativo sobre otro, osea tener dos "computadores" en uno.

¿pero como se logra esto?

esto se logra engañando al sistema operativo virtualizado haciendole cree que corre sobre hardware. esto se logra tomando todas las señales que envia el sistema operativo virtualizado al hardware y desviarlas via un programa al sistema operativo local para que las realice, mejor vamos a una grafica para entender mejor la idea.

SOV


v
Interprete

v
SOL


v
Hardware

ahi se ve como el sistema operativo virtualizado envia las intrucciones que toma el interprete las traduce de forma que el sistema operativo local las entienda y este las envia al hardware. para las respuestas de hardware es lo mismo pero al reves.

¿Que sistema de virtulizacion usaremos?

Usaremos UML(user mode linux) el mejor sistema de virtulizacion y que ademas esta incluido en la fuentes del kernel desde las ultimas versiones 2.4. este sistema de virtulizacion solo sirve para correr Linux sobre Linux.
Aunque UML es muy facil de ocupar e instalar mejor usaremos una variante de este especialmente diseñado par virtulizar redes NetKit. Netkit es una serie de script que se ocupan en conjunto con UML para facilitar tanto la creacion de maquinas virtulaes(sistemas operativos virtulizados) como todo lo necesario para conectarlos en una red(switch virtuales).

¿pero que puedo hacer no esto?

de todo lo posible en redes, desde crear una red lan hasta multiples sistemas autonomos corriendo BGP(vease documentacion netkit.org) y esto corriendo solo en un computador normal(ejemplo el mio es solo un duron de 1.4GHz y 256MB de ram).

¿pero como lo hago?

Instalacion

la instalacion de Netkit es muy facil y las dependencias son comandos estardares de GNU/Linux:

-descarga las fuentes desde Netkit.org
-Descomprime todo.
-ahora en la cosola debes agregar esto al PATH para que puedas despues encontrar los comando(y se encuentren entre ellos)
export NETKIT_HOME=/home/foo/netkit2
export MANPATH=:$NETKIT_HOME/man
export PATH=$NETKIT_HOME/bin:$PATH

-luego corre el archivo de verificacion de la instalacion
./check_configuration.sh
y si todo esta bien estamos listos

¿pero que es todo esto?

Ahora te voy a explicar bien que es UML. UML es un kernel modificado para poder correr sobre otro kernel, pero para el kernel pueda hacer algo necesita un sistema de ficheros, archivos y programas. al descargar netkit-2.4.tar.bz2 descargas el kernel modificado y las herramientas para crear redes, ya l descargar netkit-filesystem-F3.0a.tar.bz2 descragas el sistema de ficheros.

¿como lo ocupo?

Bueno si la instalacion te sali perfecta, para crear una maquina virtual solo debes usar el comando
vstart [nombre_MV] [Interface_de_red]
y tendras otro "computador corriento. para detenerlo
vhalt [nombre_MV]

¿pero como creo una red?

eso es muy facil, supongamos que queremos conectar los maquinas virtuales pc1 y pc2

PC1<------switcha------>PC2

vstart pc1 eth0=A
vstart pc2 eth0=A


y listo puedes hacer ping y ver que las maquinas se comunican y listo.


¿y que hago despues?

bueno puedes crear redes mas complejas. mira la documentacion en netkit.org y podras ver un gran numero de posiblidades.

Espero incluir unas configuraciones mas complejas en el foro asi que esperen


pd: si quieren algun tema en especial de redes pidan haber si puedo hacer algo
_________________
Quienes son capaces de renunciar a la libertad esencial a cambio de una pequeña seguridad transitoria, no son merecedores ni de la libertad ni de la seguridad.