En la jaula de un geek

Los README son para los cobardes. Sé valiente. Ejecuta el programa.

«

»

Nov 27

Kubernetes con volumen GlusterFS (Centos 8)

Kubernetes tiene varias opciones para crear volúmenes, en otro artículo ya expliqué cómo utilizar NFS, ahora le toca a algo más profesional: GlusterFS.

GlusterFS es un sistema de réplica de datos, similar a crear una RAID a nivel de software, aunque tiene algunos extras, como la capacidad de hacer snapshots o la georeplicación. En caso de Kubernetes, únicamente nos interesa su capacidad para crear réplicas de los datos y compartirlas, similar a una carpeta compartida.

Debo avisar que GlusterFS es realmente grande y Kubernetes no está configurado «por defecto» para utilizarlo (requiere un intermediario: Heketi), así que su configuración es bastante compleja, y además hará falta obtener conocimientos de GlusterFS para gestionarlo manualmente si fuera necesario.

Explicación

Kubernetes es capaz de conectar con servicios externos siempre y cuando estos dispongan de un servicio REST, GlusterFS no dispone de estos, funciona por comandos para gestionar todo, y desde cualquier nodo se puede gestionar al resto.

Por otro lado, tenemos Heketi, que genera una capa por encima de GlusterFS, conecta con cada uno de los nodos para darles ordenes, aun así, Heketi tiene varios problemas:

  • Requiere desplegar un servicio REST, si este servicio falla, ya no se tiene acceso a la gestión del GlusterFS, así que es recomendable tener un clúster de este servicio
  • GlusterFS funciona creando volúmenes, los volúmenes creados manualmente, fuera de Heketi, no pueden ser configurados desde este
  • Heketi requiere una base de datos donde almacenar su información, lo que acaba siendo un problema, queremos solucionar el problema de no perder datos de volúmenes y este acaba teniendo ese mismo problema
  • Existe un proyecto con GlusterFS y Heketi para Kubernetes, que permite desplegar GlusterFS en todos los nodos de Kubernetes, despliega Heketi en clúster dentro del Kubernetes y se encarga de todo, genial ¿verdad? Pues no funciona tan bien como parece.

GlusterFS se recomienda desplegar con al menos 3 nodos, aunque todos se despliegan de la misma forma, con lo que explicaré uno y simplemente habrá que replicar los mismos pasos. En mi caso utilizaré los mismos nodos de Kubernetes como nodos de GlusterFS, aunque estos pasos se pueden utilizar para desplegar el GlusterFS sobre otros servidores.

Utilizaré el Kubernetes desplegado sobre CentOS 8 explicado anteriormente. Sea como sea, todos los nodos deben ser capaces de resolver su nombre, ya sea por tenerlos en un DNS o por añadirlos en el fichero /etc/hosts.

1- Preparar los nodos de GlusterFS

Cada nodo necesita un disco duro sin formatear que será el utilizado por este servicio, en mi caso será he asociado un nuevo disco duro a cada nodo que está en /dev/sdb

El script generado por el proyecto es capaz de desplegar GlusterFS en cada nodo de Kubernetes, pero en mi caso dio muchos errores, además, prefiero hacer este despliegue manualmente para tener un mejor control sobre él.

Por defecto, CentOS dispone de una versión vieja, así que habrá que activar la release propia para acceder a la última versión.

Instalamos y preparamos en cada nodo.

dnf install -y centos-release-gluster
dnf config-manager --set-enabled PowerTools
dnf install -y glusterfs-server
systemctl enable --now glusterd

Abrimos los puertos necesarios para la comunicación de GlusterFS y de Heketi además de activar los componentes que estos necesitan.

firewall-cmd --zone=public --permanent --add-port={2222,24007-24008,49152-49251}/tcp
firewall-cmd --reload
for i in dm_snapshot dm_mirror dm_thin_pool; do modprobe $i; done

A partir de aquí, ya tenemos el servicio preparado, desde cualquier nodo incluiremos al resto y comprobaremos que esté funcionando.

gluster peer probe node2.domain.intranet
gluster peer probe node3.domain.intranet
gluster pool list

Esto nos mostrará todos los nodos asociados.

UUID                                    Hostname                        State
b814471f-ee64-478f-9299-f9124877dd45    node2.moon.intranet             Connected
69c1e99d-0015-4065-bc34-a1d80b31f440    node3.moon.intranet             Connected
262b1921-5ab9-43b6-bda5-c86ae7c90920    localhost                       Connected

Esto nos deja los nodos funcionando, este servicio necesita además configurar un volumen para cada proyecto, pero le dejaremos este trabajo a Heketi.

2- Preparando el master de Kubernetes

Antes de empezar: este y los siguientes puntos empiezan a tener bastante complejidad, en algunos casos, un error nos hará eliminar manualmente varios procesos, y no tiene porqué ser fácil (puede requerir conocimientos de GlusterFS o de particiones de Linux), si disponemos de la opción de crear snapshots, será mejor utilizarlos.

El despliegue de Heketi y su preparación se puede hacer desde uno de los scripts del proyecto original, este requiere Git para descargarlo (podemos descargarlo a mano, pero es conveniente tener Git en un master de Kubernetes para poder guardar nuestros ficheros de configuración para cada despliegue) y también python, que el script utilizará para recuperar la lista de nodos.

dnf install -y git python38

CentOS nos creará la opción de python3 y python38, pero el script requiere tener «python», así que creamos un enlace blando para tenerlo disponible, ya que este problema es bastante típico y nos podrá surgir a futuro.

ln -s /usr/bin/python3 /usr/bin/python

Ahora tendremos que descargar el proyecto, pero la versión al escribir este artículo, es únicamente compatible con Kubernetes 1.6, debido a versiones que han desaparecido. En un pull request lo han solucionado para 1.8 (hay otro para 1.7), sí que utilizaré ese para ahorrarme toda la faena.

git clone --single-branch --branch fix-broken https://github.com/pkalever/gluster-kubernetes.git

Lo primero es preparar la topología de nuestro GlusterFS.

cd gluster-kubernetes/deploy/
cp topology.json.sample topology.json
vi topology.json

En este fichero indicamos el nombre del nodo según Kubernetes (kubectl get nodes) en «manage», la IP (NO funciona con nombres de dominio) en «storage» y los discos para Gluster (en mi caso solo tengo /dev/sdb) en «devices».

{
  "clusters": [
    {
      "nodes": [
        {
          "node": {
            "hostnames": {
              "manage": [
                "temp101"
              ],
              "storage": [
                "192.168.1.101"
              ]
            },
            "zone": 1
          },
          "devices": [
            "/dev/sdb"
          ]
        },
        {
          "node": {
            "hostnames": {
             "manage": [
                "temp102"
              ],
              "storage": [
                "192.168.1.102"
              ]
            },
            "zone": 1
          },
          "devices": [
            "/dev/sdb"
          ]
        },
        {
          "node": {
            "hostnames": {
              "manage": [
                "temp103"
              ],
              "storage": [
                "192.168.1.103"
              ]
           },
            "zone": 1
          },
          "devices": [
            "/dev/sdb"
          ]
        }
      ]
    }
  ]
}

También necesitamos que el master sea capaz de acceder al resto de nodos por SSH sin contraseña, para ello generamos unas claves (nos preguntará la contraseña, dejarla en blanco) y las enviamos a cada nodo.

ssh-keygen -t rsa -b 2048 -f /root/.ssh/id_rsa
ssh-copy-id -i /root/.ssh/id_rsa temp101.domain.internet
ssh-copy-id -i /root/.ssh/id_rsa temp102.domain.internet
ssh-copy-id -i /root/.ssh/id_rsa temp103.domain.internet

Crearemos un namespace para que todo lo relacionado con Heketi y GlusterFS quede separado del resto.

kubectl create namespace glusterfs

Y terminamos con un pequeño detalle, al crear el PersistentVolume, tendremos que indicar una URL que el master debe ser capaz de resolver fuera de Kubernetes, por si mismo, así que o publicamos este REST a través de Ingress o similar, o utilizamos el nombre interno que genera Kubernetes para acceder a los deployments (<service>.<namespace>.svc.cluster.local), este último es el más práctico pero no es accesible por defecto, así que habrá que modificarlo.

vi /etc/kubernetes/manifests/kube-controller-manager.yaml

Añadimos la siguiente línea encima de «hostNetwork: true», nos quedará así:

dnsPolicy: ClusterFirstWithHostNet
hostNetwork: true

Reiniciamos el kubelet para aplicar este cambio.

systemctl restart kubelet

Debo avisar que este cambio permite a los servicios como un PersistentVolume utilizar los DNS internos de Kubernetes, pero nuestro servidor seguirá sin poderlos utilizar.

3- Desplegar Heketi

Ya tenemos todo lo necesario para desplegar Heketi, crear un volumen de GlusterFS donde almacenar su base de datos y hacer que Heketi se despliegue totalmente en Kubernetes utilizando ese volumen, todo esto se puede hacer con el script que viene en el proyecto descargado por Git.

Cambiar los user-key y admin-key por vuestra contraseña.

Antes de ejecutarlo, este proceso es muy complejo de revertir, es el momento ideal para un snapshot.

./gk-deploy \
   --user-key heketi \
   --admin-key heketi \
   --ssh-keyfile /root/.ssh/id_rsa \
   --ssh-user root \
   --cli kubectl \
   --no-object \
   --templates_dir ./kube-templates \
   --namespace glusterfs \
   topology.json

Si todo ha ido bien, al terminar nos mostrará los pasos a seguir, aunque en la versión actual los logs son algo ilegibles, pero encontraremos algo como:

heketi is now running and accessible via http://10.244.227.197:8080 . To run
administrative commands you can install 'heketi-cli' and use it as follows:

  # heketi-cli -s http://10.244.227.197:8080 --user admin --secret 'heketi' cluster list

You can find it at https://github.com/heketi/heketi/releases . Alternatively,
use it from within the heketi pod:

  # kubectl -n glusterfs exec -i heketi-68ffb8d4b5-b9gk9 -- heketi-cli -s http://localhost:8080 --user admin --secret 'heketi' cluster list

Podemos confirmar el funcionamiento con la web de hello de Heketi.

curl http://10.244.227.197:8080/hello

Y ver todo lo desplegado en el nuevo namespace.

kubectl get all -n glusterfs

Este es mi resultado.

NAME                          READY   STATUS    RESTARTS   AGE
pod/heketi-68ffb8d4b5-b9gk9   1/1     Running   0          7m18s

NAME                               TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/heketi                     ClusterIP   10.99.152.1     <none>        8080/TCP   7m19s
service/heketi-storage-endpoints   ClusterIP   10.111.76.220   <none>        1/TCP      7m26s

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/heketi   1/1     1            1           7m19s

NAME                                DESIRED   CURRENT   READY   AGE
replicaset.apps/heketi-68ffb8d4b5   1         1         1       7m19s

Si todo es correcto, ¡genial! no es nada fácil llegar a hacerlo funcionar (en serio, no lo es …), pero aún no hemos acabado.

Tal como indica, se necesita tener el heketi-cli o utilizar el contenedor como intermediario, para tener más facilidad yo prefiero descargarlo y así tenerlo más a mano.

Actualmente tenemos 2 opciones, o descargar únicamente el cliente, o tener todo el paquete con ejemplos, estos comandos descargan ambos para que cada cuál pueda elegir, si alguno no te interesa, siempre lo puedes borrar.

cd /root
dnf -y install wget
curl -s https://api.github.com/repos/heketi/heketi/releases/latest \
  | grep browser_download_url \
  | grep linux.amd64 \
  | cut -d '"' -f 4 \
  | wget -qi -
for i in `ls | grep heketi | grep .tar.gz`; do tar xvf $i; done
sudo cp ./heketi-client/bin/heketi-cli /usr/local/bin

Ahora ya tendremos acceso al cliente de heketi, podemos confirmarlo.

heketi-cli --version

Cada comando que utilicemos habrá que pasarle la URL, usuario y contraseña, pero podemos declarar las variables (se pierden al cerrar la sesión, aunque podemos definirlas de otras formas para mantenerlas u ocultar mejor la contraseña).

export HEKETI_CLI_SERVER=$(kubectl get svc/heketi -n glusterfs --template 'http://{{.spec.clusterIP}}:{{(index .spec.ports 0).port}}')
export HEKETI_CLI_USER=admin
export HEKETI_CLI_KEY=heketi

Ya podremos conectar, estos son algunos de los comandos y respuestas típicas.

heketi-cli cluster list

Resultado:

Clusters:
Id:fa99c84472256051fc07b16203003653 [file][block]

Información del clúster.

heketi-cli cluster info fa99c84472256051fc07b16203003653

Resultado:

Cluster id: fa99c84472256051fc07b16203003653
Nodes:
0161cae81231a04f4ae0f5425ce406d5
4fcbf4f80645e74d0b65fe98c5904993
d968f2c17bfbda5b29c5d49a2332eec4
Volumes:
c3afbd040a6cb35b317b6a1436353def
Block: true

File: true

Información de nodos.

heketi-cli node list

Resultado:

Id:0161cae81231a04f4ae0f5425ce406d5     Cluster:fa99c84472256051fc07b16203003653
Id:4fcbf4f80645e74d0b65fe98c5904993     Cluster:fa99c84472256051fc07b16203003653
Id:d968f2c17bfbda5b29c5d49a2332eec4     Cluster:fa99c84472256051fc07b16203003653

Topología.

heketi-cli topology info

Quizás el más importante sea la lista de volúmenes.

heketi-cli volume list

Resultado:

Id:c3afbd040a6cb35b317b6a1436353def    Cluster:fa99c84472256051fc07b16203003653    Name:heketidbstorage

También podemos utilizar los comandos desde el contenedor.

kubectl exec -i heketi-68ffb8d4b5-b9gk9 -n glusterfs -- heketi-cli --user admin --secret heketi -s http://localhost:8080 cluster list

4- Añadir servicio

Necesitamos definir un StorageClass que hará de base, todos los PersistentVolumeClaim irán asociados a él, en mi caso le asociaré un secret a la contraseña, si indicáramos la contraseña visible como otro parámetro podríamos unificar el storageclass dentro del namespace de glusterfs y reutilizarlo en todos los sitios, pero con un secret de por medio únicamente he logrado errores, así que en cada namespace se generará el storageclass y su secret, en mi caso lo dejaré en default.

Definimos el gluster-storageclass.yaml.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: glusterfs-storage
provisioner: kubernetes.io/glusterfs
allowVolumeExpansion: true
reclaimPolicy: Retain
parameters:
  resturl: "http://heketi.glusterfs.svc.cluster.local:8080"
  restauthenabled: "true"
  restuser: "admin"
  secretNamespace: "default"
  secretName: "heketi-secret"

Para utilizar esto necesitamos crea un secret, primero prepararemos la contraseña.

echo -n "heketi" | base64

Que utilizaremos para crear el secret, heketi-secret.yaml.

apiVersion: v1
kind: Secret
metadata:
  name: heketi-secret
  namespace: default
data:
  key: aGVrZXRp
type: kubernetes.io/glusterfs

Con esto ya podemos definirlo dentro del namespace de glusterfs.

kubectl apply -f gluster-storageclass.yaml
kubectl apply -f heketi-secret.yaml

Podemos confirmar que se ha creado.

kubectl get storageclass

Resultado:

NAME                PROVISIONER               RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
glusterfs-storage   kubernetes.io/glusterfs   Retain          Immediate           true                   7s

5- Desplegar Nginx en GlusterFS

Ya podemos crear un PersistentVolumeClaim (PVC) para que lo utilice Nginx, gluster-pvc-nginx.yaml.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gluster-nginx
  annotations:
    volume.beta.kubernetes.io/storage-class: glusterfs-storage
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi

Al crear el PVC, se genera el volumen con Heketi, así que lo crearemos y confirmamos que todo funcione antes de utilizarlo.

kubectl apply -f gluster-pvc-nginx.yaml

El PVC contendrá el volumen de GlusterFS y será el que utilizaremos para Nginx.

kubectl get pvc

Resultado:

NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
gluster-nginx   Bound    pvc-e92993a2-5c38-4290-972d-e0fd55e0190f   1Gi        RWX            glusterfs-storage   4s

Si ha funcionado, también nos habrá creado el PV.

kubectl get pv

Resultado:

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                   STORAGECLASS        REASON   AGE
pvc-e92993a2-5c38-4290-972d-e0fd55e0190f   1Gi        RWX            Retain           Bound    default/gluster-nginx   glusterfs-storage            49s

Ahora ya podemos desplegar el Nginx, nginx-deployment.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
        volumeMounts:
        - name: gluster-storage
          mountPath: "/usr/share/nginx/html"
      volumes:
        - name: gluster-storage
          persistentVolumeClaim:
            claimName: gluster-nginx

Desplegamos y revisamos que los pods se desplieguen.

kubectl apply -f nginx-deployment.yaml
kubectl get pods -l app=nginx

6- Test y gestión de Heketi/GlusterFS

Con Nginx ejecutado sobre un nuevo volumen de GlusterFS, queda hacer las pruebas y entender cómo gestionar todo esto.

Podemos mostrar la lista de volúmenes de Heketi.

heketi-cli volume list

Nos mostrará el volumen con la base de datos de Heketi y el nuevo.

Id:859c773486f43186c95f35e67aab16f3    Cluster:fa99c84472256051fc07b16203003653    Name:vol_859c773486f43186c95f35e67aab16f3
Id:c3afbd040a6cb35b317b6a1436353def    Cluster:fa99c84472256051fc07b16203003653    Name:heketidbstorage

Perfecto, tenemos el identificador de Heketi, el name corresponde a su mismo valor en GlusterFS, pero ¿qué pasa cuando tengamos 5? No hay forma de saber qué volumen de Kubernetes corresponde a cuál en GlusterFS. Para resolver esto primero hay que entender un poco más de cómo funciona todo esto.

Al crear un PVC, este llama a Heketi para crear un nuevo volumen y que él se encargue de crearlo en los nodos de GlusterFS, Heketi genera un Id para el nuevo volumen y lo devuelve, él no almacena nada externo, para solucionar esto, el PV creado por el PVC sí que almacena el identificador de Heketi (que además necesitará si, por ejemplo, quisiéramos hacer modificaciones del volumen), debido a que es un dato especial, con un get no podemos extraerlo, pero se puede conseguir con una template.

kubectl get pv -o 'go-template={{range .items}}name={{.metadata.name}} claimName={{.spec.claimRef.name}} heketiName={{.spec.glusterfs.path}}{{"\n"}}{{end}}'

Este nos devuelve el Id del volumen de Kubernetes, el nombre de nuestro PVC y el nombre del volumen en GlusterFS.

name=pvc-e92993a2-5c38-4290-972d-e0fd55e0190f claimName=gluster-nginx heketiName=vol_859c773486f43186c95f35e67aab16f3

Con esto podemos ir a uno de los nodos y mirar el listado de volúmenes.

gluster volume list

Ahora sí, podemos identificar el volumen real.

heketidbstorage
vol_859c773486f43186c95f35e67aab16f3

Y, con ello, extraer toda la información del volumen.

gluster volume info vol_859c773486f43186c95f35e67aab16f3

Por defecto todos los volúmenes son Replica 3, y podemos ver en qué rutas está exactamente.

Volume Name: vol_859c773486f43186c95f35e67aab16f3
Type: Replicate
Volume ID: 0e71dcd2-f61b-4c3b-bc3f-28cbdb068d0b
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: 192.168.1.101:/var/lib/heketi/mounts/vg_9c3e257deb0838270b381143e13967bd/brick_333a40b9e79cb3f21c8bea92c37f79cc/brick
Brick2: 192.168.1.102:/var/lib/heketi/mounts/vg_0809f47b291fc6fa26987242a220208f/brick_9078029f46a1fca8ac744a8f0671f130/brick
Brick3: 192.168.1.103:/var/lib/heketi/mounts/vg_b415991f501d9c99d7281aa32210bc86/brick_5855346072f62e0bdd5612fa3dc5f9c5/brick
Options Reconfigured:
user.heketi.id: 859c773486f43186c95f35e67aab16f3
storage.fips-mode-rchecksum: on
transport.address-family: inet
nfs.disable: on
performance.client-io-threads: off

Ya tenemos lo suficiente para hacer pruebas, así que accedemos a uno de los pods, mirando en qué nodo está, y nos vamos a un nodo diferente para acceder a su ruta de montaje para crear y listar ficheros desde nodos diferentes y confirmar que la réplica está funcionando.

kubectl get pods -o wide -l app=nginx
kubectl exec -it nginx-deployment-68fb6b7489-cbz5n -- bash

Aquí creamos un fichero nuevo y comprobamos que nos aparece.

cd /usr/share/nginx/html
echo "Hello from GlusterFS" > index.html
curl localhost

Si desde un nodo vamos a la ruta que nos indica el volumen y mostramos los ficheros, encontraremos el index.html

cd /var/lib/heketi/mounts/vg_0809f47b291fc6fa26987242a220208f/brick_9078029f46a1fca8ac744a8f0671f130/brick
ls

Si seguimos probando, veremos que podemos crear un fichero en el nodo y este será mostrado por Nginx, aun así, debo advertir que las réplicas no son inmediatas, y, curiosamente, habrá veces que curl sea capaz de mostrar ficheros que con ls aun no vemos.

7- Borrar volumenes

Cuando borramos un PVC, este borrará el PV, pero no borrará ni el volumen en Heketi ni en GlusterFS, y debido a que la asociación con estas particiones es dinámica, cuando creamos un nuevo PVC, este creará un nuevo volumen en vez de reutilizar uno anterior, así que ojo con ello, ya que con esta configuración nunca podremos reenganchar con un volumen ya creado si perdemos su PVC.

Por esta misma regla, debido a que utilizamos el PV para identificar qué volumen de Kubernetes corresponde a qué volumen en GlusterFS, si lo borramos sin mirar antes la correspondencia, nos será más difícil de encontrar el volumen a borrar.

También hay que tener en cuenta, que la gestión de volúmenes se hace desde Heketi, si borramos un volumen directamente en GlusterFS, Heketi no lo sabrá y nos dará información errónea.

Borrar requiere un orden, primero debemos utilizar el comando explicado previamente para obtener los Ids de los volúmenes a cada lado.

kubectl get pv -o 'go-template={{range .items}}name={{.metadata.name}} claimName={{.spec.claimRef.name}} heketiName={{.spec.glusterfs.path}}{{"\n"}}{{end}}'

De este podemos extraer la siguiente información:

  • name=pvc-e92993a2-5c38-4290-972d-e0fd55e0190f: Nombre del PV a borrar, si reemplazamos «pvc-» por «glusterfs-dynamic-«, obtendremos el service a borrar
  • claimName=gluster-nginx: Nombre del PVC a borrar
  • heketiName=vol_859c773486f43186c95f35e67aab16f3: Si eliminamos el «vol_», obtenemos el Id necesario para borrar el volumen

Con estos datos procedemos a borrar toda la información del volumen en todos los lugares.

kubectl delete pvc/gluster-nginx pv/pvc-e92993a2-5c38-4290-972d-e0fd55e0190f services/glusterfs-dynamic-e92993a2-5c38-4290-972d-e0fd55e0190f
heketi-cli volume delete 859c773486f43186c95f35e67aab16f3

La destrucción del volumen en Heketi, también destruirá los datos en GlusterFS, así que cuidado con ello.

Final

Llegar hasta aquí no es nada fácil, y mucho me temo que en próximas versiones, algunos de estos pasos pueden dejar de funcionar como ha ido pasando en cada versión de Kubernetes.

También, el despliegue de Heketi dentro de Kubernetes nos hace la vida mucho más sencillo, pudiendo crear automáticamente PVC y que estos se encarguen de todo, si utilizaramos GlusterFS y lo compartiéramos con otros métodos, nos obligaría a tener que crear manualmente los volúmenes, o a utilizar los comandos de Heketi para hacerlo manualmente, esto no es algo malo, simplemente es más lento y puede entorpecer a algunos sistemas, sobretodo a aquellos más automatizados, es nuestra elección decidir qué preferimos.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar