Restore an old file version with Puppet Bucket

Restore an old file version with Puppet Bucket

What happens if you deploy a wrong configuration with puppet to your servers? or if you want to try an old configuration in one of your servers?

It's not big deal if you use puppet because by default it does versioning of your modicated files, this could be used as backup if needed

The sintax to restore an old version of your file is

puppet filebucket restore -b /bucketdirectory /path/file MD5

By default on RHEL/CentOS/Fedora systems bucket directory is /var/lib/puppet/clientbucket

MD5 is the md5sum of your old file version, this hash we could find it on puppet logs

Example:

puppet filebucket restore -b /var/lib/puppet/clientbucket/ /etc/passwd 379aa0669894ff4150ec2dad28622216

A practical example:
Let's suppose we have a file /root/file-test.txt

[root@nodo ~]# cat /root/file-test.txt.txt
This is a rollback test

After execute puppet agent, it modifies our file:

[root@nodo ~]# puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for nodo.infratic.com
Info: Applying configuration version ‘1416421872’
Notice: /Stage[main]/Basico/File[/root/file-test.txt]/content:
— /root/archivo-test.txt 2014-11-19 15:40:49.248857861 -0300
+++ /tmp/puppet-file20141119-7388-tkwcex-0 2014-11-19 15:41:04.858857840 -0300
@@ -1 +1 @@
-This is a rollback test
+This should not be here
 
Info: Computing checksum on file /root/file-test.txt.txt
Info: FileBucket got a duplicate file {md5}379aa0669894ff4150ec2dad28622216
Info: /Stage[main]/Basico/File[/root/file-test.txt]: Filebucketed /root/file-test.txt to puppet with sum 379aa0669894ff4150ec2dad28622216
Notice: /Stage[main]/Basico/File[/root/file-test.txt]/content: content changed ‘{md5}379aa0669894ff4150ec2dad28622216’ to ‘{md5}3de659e5dc355b14ec5cd0606b2baef8’
Notice: Finished catalog run in 0.79 seconds

After finished execution agent notified us that it change our file content, and it shows the old md5sum and the new one:
Notice:/Stage[main]/Basico/File[/root/archivo-test.txt]/content: content changed ‘{md5}379aa0669894ff4150ec2dad28622216’ to ‘{md5}3de659e5dc355b14ec5cd0606b2baef8’

Let's check file was modified:

[root@nodo ~]# cat /root/archivo-test.txt
This should not be here

Rollback to old file version:

[root@nodo ~]# puppet filebucket restore -b /var/lib/puppet/clientbucket/ /root/file-test.txt 379aa0669894ff4150ec2dad28622216

Finally we would check if we restore our file

[root@nodo ~]# cat /root/file-test.txt.txt
This is a rollback test

Puppet Bucket is a great tool to rollback your configurations or easy recover old file versions. This could save our heads if we make a mistake in a critical configuration file

Extender disco virtual creado con la opción Thick Provision Eager Zeroed VMWare 5.5

Extender disco virtual creado con la opción Thick Provision Eager Zeroed

Si tenemos un disco del tipo Thick Provision Eager Zeroed compartido entre 2 nodos y la extendemos a traves de la interfaz grafica la maquina virtual tendrá errores al levantar, errores como:

An error was received from the ESX host while powering on VM nodo1.
Failed to start the virtual machine.
Module DiskEarly power on failed.
Cannot open the disk '/vmfs/volumes/55788bcb-66e4405e-8d19-441ea15c3790/nodo1/nodo1_1.vmdk' or one of the snapshot disks it depends on.
Thin/TBZ/Sparse disks cannot be opened in multiwriter mode.
VMware ESX cannot open the virtual disk "/vmfs/volumes/55788bcb-66e4405e-8d19-441ea15c3790/nodo1/nodo1_1.vmdk" for clustering. Verify that the virtual disk was created using the thick option.

El problema radica en que cuando se extiende a traves de interfaz grafica el disco con el nuevo tamaño queda en formato Thick Provison Lazy Zeroed y dicho formato no soporta estar activo en varias maquinas virtuales

La forma correcta de hacerlo

La forma correcta de hacerlo es la siguiente:

  • Apagamos todos los nodos que accedan al disco compartido
  • Ingresamos por SSH a uno de los nodos esx que tenga acceso al DS
  • Extendemos el disco virtual con el comando vmkfstools

La sintaxis del comando vmkfstools para este caso es la siguiente:

vmkfstools -X <nuevo_tamaño> -d eagerzeroedthick <ruta_del_disco_virtual>

La <ruta_del_disco_virtual> normalmente seria la siguiente:
/vmfs/volumes/<Nombre_del_DS>/<nombrevm>/<archivo>.vmdk

Ej:
Si queremos extender un disco virtual hasta los 100GB, teniendo en cuenta los siguientes datos:

DataStore: VSP
Nombre de la maquina virtual: nodo1
Nombre del disco: nodo1.vmdk

El comando seria

vmkfstools -X 100G -d eagerzeroedthick /vmfs/volumes/VSP/nodo1/nodo1.vmdk

Luego podemos encender de vuelta todas las maquinas virtuales y las mismas ya deberian de ver el disco con el nuevo tamaño

Es muy importante que la extension se haga de la forma comentada, caso contrario las VM no encenderian y se tendrian que realizar varias tareas para recuperar los datos

Configurar Logstash para que obtenga datos de una base de datos SQL

Configurar Logstash para que obtenga datos de una base de datos SQL

En caso de que necesitemos que nuestro logstash obtenga datos de una base de datos lo podemos hacer utilizando el plugin logstash-input-jdbc para establecer la conexión y ejecutar las consultas directamente desde nuestro logstash

El plugin logstash-input-jdbc

Este plugin nos permite configurar como input de logstash cualquier fuente a la que se puede acceder con Java JDBC

En este tutorial configuraremos logstash para que acceda a una base de datos MySQL/MariaDB, luego ejecute una consulta SQL, una vez que reciba los datos los mismos pueden ser tratados con cualquier filtro que tengamos definido en nuestro logstash

Este turorial esta basado en:

S.O. : CentOS 7.2
Logstash : 5.0

Obtener el driver JDBC

Lo primero que tenemos que hacer es obtener el driver JDBC a utilizar, en este caso lo podemos descargar de https://dev.mysql.com/downloads/connector/j/, una vez que descarguemos el .zip debemos copiar el .jar que se encuentra dentro del mismo a nuestro servidor logstash a la ruta /etc/logstash/jdbc/mysql-connector-java.jar

mkdir /etc/logstash/jdbc
chown -R logstash /etc/logstash/jdbc
wget https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-5.1.40.zip
unzip mysql-connector-java-5.1.40.zip
mv mysql-connector-java-5.1.40/mysql-connector-java-5.1.40-bin.jar /etc/logstash/jdbc/mysql-connector-java.jar

Con esto tendremos listo nuestro driver JDBC, ahora podemos comenzar a configurar el logstash

Instalar y configurar el plugin logstash-input-jdbc

Para instalar el plugin debemos ejecutar el siguiente comando:

/usr/share/logstash/bin/logstash-plugin install logstash-input-jdbc

Una vez instalado el plugin debemos configurar el input de logstash, para esto creamos el archivo /etc/logstash/conf.d/01-mysql-jdbc.conf

vi /etc/logstash/conf.d/01-mysql-jdbc.conf
input {
   jdbc {
    # Ruta del driver JDBC que utilizaremos
    jdbc_driver_library => "/etc/logstash/jdbc/mysql-connector-java.jar"
    # Clase a utilizar (consultar documentacion del driver)
    jdbc_driver_class => "com.mysql.jdbc.Driver"            
    # URl de la conexion a base de datos, deben reemplazar el host y el nombre de la BD
    jdbc_connection_string => "jdbc:mysql://host:3306/basededatos"
    # Usuario con el cual se conectara a la BD
    jdbc_user => "user"
    # Password del usuario
    jdbc_password => "pass"
    # Activa la opcion para utilizar el nombre de las columnas como nombre del campo
    use_column_value => "true"
    # Define que columna se utilizara para hacer el seguimiento de las consultas
    tracking_column => "fecha"
    # Se activa la opcion de registrar la última consulta
    record_last_run => "true"
    # Ruta donde se guardara un registro de la última consulta
    last_run_metadata_path => "/etc/logstash/jdbc/registro_volmap_last_run"
    # Consulta SQL, la variable :sql_last_value se reemplaza por el ultimo valor obtenido de la columna que se definio en tracking_column
    # con esto evitamos que logstash reciba datos repetidos, debido a que filtra los valores que se crearon luego de la última vez que
    # el consulto
    statement => "SELECT fecha, monto FROM ventas WHERE fecha > :sql_last_value"  
    # Desactiva la opcion de ejecutar una consulta como si fuese la primera vez siempre
    clean_run => "false"
    # Podemos definir los tags que tendran los datos recolectados
    tags => "mysql-jdbc"
    # Agendamos la ejecucion en formato crontab
    # Para que se ejecute cada 1 minuto: * * * * *
    schedule => "* * * * *"
   }
}

Una vez que guardamos en caso de que tengamos configurado nuestro logstash con autoreload veríamos en unos minutos que se ejecuta la consulta en el log /var/log/logstash/logstash-plain.log

Caso contrario debemos reiniciar el servicio logstash para que tome los cambios

Con esto tenemos una fuente JDBC como input de logstash, tal como dije al inicio, para logstash es como cualquier otro input por lo tanto podemos agregar filtros como si fuese un log normal

Para más informacion:
https://www.elastic.co/guide/en/logstash/current/plugins-inputs-jdbc.html

Configurar elasticsearch x-pack para autenticar via LDAP

Configurar elasticsearch x-pack para autenticar via LDAP

Con el plugin x-pack de elasticsearh es posible que tanto nuestro elasticsearch como kibana utilice usuarios externos, los cuales pueden ser de LDAP, Active Directory o archivos

En este caso configuraremos nuestro elasticsearch para que autentique a traves de LDAP para los usuarios clientes y que autentique también vía archivos para los usuarios genéricos tales como el logstash, de manera a que en caso de que nuestro servidor LDAP tenga problemas no perdamos los datos que estén tratando de insertar en ese momento.

Configurar autenticacion vía LDAP

Lo primero que tenemos que hacer es asegurarnos de que nuestro LDAP acepte consultas anonimas, luego debebemos obtener los datos que necesitaremos:

- base dn: El DN donde el elasticsearch ejecutara la busqueda cuando un usuario trate de conectarse
- ldap url: Nombre o Ip de nuestro servidor LDP
- group base dn: El DN donde el elasticesarch buscara los grupos
- atributo de usuario: el atributo LDAP de nombre de usuario, normalmente es "cn" o "uid"

Una vez que tenemos todos esos datos debemos agregar al final del archivo /etc/elasticsearch/elasticsearch.yml lo siguiente:

xpack:
  security:
    authc:
      realms:
        ldap1:
          type: ldap
          order: 1
          url: "ldap://ldap.infratic.com:389"
          user_search:
            base_dn: "ou=People,dc=infratic,dc=com"
            attribute: uid
          group_search:
            base_dn: "ou=Groups,dc=infratic,dc=com"
          files:
            role_mapping: "/etc/elasticsearch/x-pack/role_mapping.y
          unmapped_groups_as_roles: false

Configurar roles para los usuarios y grupos de LDAP

Una vez que tenemos configurada la autenticacion via LDAP solo nos queda asignar los roles correspondientes a los grupos o usuarios, esto se hace en el archivo /etc/elasticsearch/x-pack/role_mapping.yml, por ejemplo:

superuser:
        # Para asignar el role a un usuario especifico
        - "uid=supervisor,,ou=People,dc=infratic,dc=com"
        # Para asignar el role a un grupo
        - "cn=administradores,ou=Groups,dc=infratic,dc=com"

Configurar autenticacion vía archivos locales

Es importante contar con un medio de autenticacion que no dependa de otros equipos para usuarios genéricos como el del logstash, esto para evitar que el logstash deje de insertar a elasticsearch cuando nuestro LDAP tenga problemas, es por eso que configuraremos también el método de autenticacion vía archivos:

Lo unico que debemos hacer es agregar al final del archivo /etc/elasticsearch/elasticsearch.yml lo siguiente:

        file1:
          type: file
          order: 0

Administrar usuarios locales

Una vez que agregamos la configuracion para autenticar via archivos locales, podemos administrar los usuarios con la herramienta /usr/share/elasticsearch/bin/x-pack/users.

Para crear un usuario:

/usr/share/elasticsearch/bin/x-pack/users useradd logstash

Para agregar un role a un usuario ya creado:

/usr/share/elasticsearch/bin/x-pack/users roles logstash -a superuser

Con el comando anterior asignamos el role superuser al usuario creado previamente.

Aplicar los cambios

Debemos reiniciar nuestro elasticsearch para que aplique todos los cambios que hicimos:

systemctl restart elasticsearch

Finalmente tenemos nuestro elasticsearch con 2 metodos de autenticaion, uno el metodo de archivos locales y el otro un servidor LDAP, no esta de mas decir que estos metodos son para autenticar usuarios, la creacion de roles se debe seguir haciendo a traves de la api del x-pack

Para mas informacion:

https://www.elastic.co/guide/en/x-pack/current/ldap-realm.html
https://www.elastic.co/guide/en/x-pack/current/file-realm.html
https://www.elastic.co/guide/en/x-pack/current/security-api-roles.html

Instalar ELK 5.0 en CentOS/RHEL/SL 7

Instalar ELK 5.0 en CentOS 7

Instalar pre-requisitos

Antes de comenzar debemos asegurarnos de tener instalados todos los paquetes necesarios:

yum install -y wget

Instalar java

Es necesario instalar la version 8 de java de Oracle, lo que lo podemos hacer con los siguientes comandos:

wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/8u73-b02/jdk-8u73-linux-x64.rpm"
yum -y localinstall jdk-8u73-linux-x64.rpm

Configurar los repositorios necesarios

Cada producto tiene su propio repositorio, podemos configurar dichos repositorios con el siguiente comando:

cat <<EOF > /etc/yum.repos.d/elk-5.0.repo
[elasticsearch-5.x]
name=Elasticsearch repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
 
[logstash-5.x]
name=Elastic repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
 
[kibana-5.x]
name=Kibana repository for 5.x packages
baseurl=https://artifacts.elastic.co/packages/5.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
EOF

Instalar elasticsearch

yum install -y elasticsearch

Una vez que instalamos elasticsearch debemos iniciar y habilitar el servicio

systemctl start elasticsearch
systemctl enable elasticsearch

Instalar logstash

yum install -y logstash

Luego debemos iniciar y habilitar el servicio

systemctl start logstash
systemctl enable logstash

Instalar kibana

yum install -y kibana

Procedemos a iniciar y habilitar el servicio

systemctl start kibana
systemctl enable kibana

Teniendo en cuenta que utilizaremos SystemD podemos eliminar el script de SysV para evitar conflictos:

rm /etc/init.d/kibana

Instalacion de plugins de logstash

Debemos instalar los plugins basicos que vamos a necesitar en nuestro logstash

/usr/share/logstash/bin/logstash-plugin install logstash-output-elasticsearch logstash-input-file logstash-input-beats

En caso de querer configurar el "autoreload" para el logstash debemos editar el archivo /etc/systemd/system/logstash.service

vi /etc/systemd/system/logstash.service

y agregamos --config.reload.automatic a la linea que inicia cono ExecStart
quedando de la siguiente manera:

ExecStart=/usr/share/logstash/bin/logstash "--path.settings" "/etc/logstash" --config.reload.automatic

Guardamos el archivo y reiniciamos el logstash para que tome los cambios

systemctl daemon-reload
systemctl restart logstash

Configurar X-PACK para elasticsearch y kibana

x-pack es el nuevo complemento que trae el stack elk en la version 5.0, basicamente lo que hace este plugin es "segurizar" el nuestro elasticsearch utilizando usuarios para acceder y roles para permitir el acceso a los distintos documentos

Debemos descargar el plugin x-pack:

cd /tmp
wget https://artifacts.elastic.co/downloads/packs/x-pack/x-pack-5.0.0.zip

Instalamos el plugin a nuestro elasticsearch y le otorgamos todos los permisos que solicita el mismo

[root@elk ~]# /usr/share/elasticsearch/bin/elasticsearch-plugin install file:///tmp/x-pack-5.0.0.zip
-> Downloading file:///tmp/x-pack-5.0.0.zip
[=================================================] 100%  
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@     WARNING: plugin requires additional permissions     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
* java.lang.RuntimePermission accessClassInPackage.com.sun.activation.registries
* java.lang.RuntimePermission getClassLoader
* java.lang.RuntimePermission setContextClassLoader
* java.lang.RuntimePermission setFactory
* java.security.SecurityPermission createPolicy.JavaPolicy
* java.security.SecurityPermission getPolicy
* java.security.SecurityPermission putProviderProperty.BC
* java.security.SecurityPermission setPolicy
* java.util.PropertyPermission * read,write
* java.util.PropertyPermission sun.nio.ch.bugLevel write
* javax.net.ssl.SSLPermission setHostnameVerifier
See http://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html
for descriptions of what these permissions allow and the associated risks.
 
Continue with installation? [y/N]y
-> Installed x-pack

Luego instalamos el plugin a nuestro kibana

[root@elk ~]# /usr/share/kibana/bin/kibana-plugin install file:///tmp/x-pack-5.0.0.zip
Attempting to transfer from file:///tmp/x-pack-5.0.0.zip
Transferring 72364732 bytes....................
Transfer complete
Retrieving metadata from plugin archive
Extracting plugin archive
Extraction complete
Optimizing and caching browser bundles...
Plugin installation complete

Luego reiniciamos los dos servicios para que tomen los cambios

systemctl restart elasticsearch logstash

Con esto tenemos instalado ELK en nuestro servidor, solo debemos comenzar a crear los filtros de logstash y recibir datos

Configurar Logstash

Debido a que instalamos x-pack debemos crear un usuario para que logstash inserte los datos a elasticsearch
Primero debemos crear el role logstash_writer el cual tendra permisos de escritura en cualquier indice

curl -XPOST "http://elastic:changeme@localhost:9200/_xpack/security/role/logstash_writer" -d '
{
  "cluster": ["manage_index_templates", "monitor"],
  "indices": [
    {
      "names": [ "*" ],
      "privileges": ["write","delete","create_index"]
    }
  ]
}'

Luego creamos el usuario y le asignamos el role recien creado

curl -XPOST "http://elastic:changeme@localhost:9200/_xpack/security/user/logstash" -d '
{ "password" : "pass_para_logstash",
  "roles" : [ "logstash_writer" ]}'

Con el comando anterior creamos el usuario logstash con el password "pass_para_logstash" con el role superuser que es el role por defecto con todos los privilegios

Agregamos un input y output basico para que nuestro logstash capture datos de rsyslog

Primero debemos agregar el input que se encargaria de leer y parsear los archivos, para esto creamos el archivo /etc/logstash/conf.d/01-rsyslog.conf

vi /etc/logstash/conf.d/01-rsyslog.conf

Y agregamos lo siguiente:

input {
  file {
    path => "/var/log/*.log"
    start_position => "beginning"
    type => "logs"
  }
}
 
filter {
 if [type] == "logs" {
   grok {
     match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
   }
   syslog_pri { }
   date {
     match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
     target => "@timestamp"
   }
 }
}

Luego agregamos el output para insertar a elasticsearch

vi /etc/logstash/conf.d/99-elastic-output.conf

y agregamos

output {
  elasticsearch {
    hosts => [ "localhost:9200" ]
    sniffing => true
    manage_template => false
    index => "%{indice}-%{+YYYY.MM.dd}"
    document_type => "%{[@metadata][type]}"
        user    => logstash
        password => password_del_logstash
  }
}

Donde se debe cambiar password_del_logstash por el password que le asignamos al usuario logstash

Finalmente configuramos el kibana para que escuche en todas las IPs del equipo
Editamos el archivo /etc/kibana/kibana.yml

vi /etc/kibana/kibana.yml

y editamos la linea

server.host: "localhost"

dejandolo de la siguiente manera:

server.host: "0.0.0.0"

Reiniciamos kibana:

systemctl restart kibana

Con esto en unos minutos podemos comenzar a ver los logs accediendo a nuestro kibana:
http://ipdenuestoserver:5601
Las credenciales por defecto son:
user: elastic
password: changeme

Luks – Formatear

Crear unidad encriptada con cryptsetup luks
Contenido

Primero procedemos a crear una particion en nuestro disco

# fdisk /dev/vdb

creamos la particion vdb1 con el formato 8e(Linux LVM)

Luego creamos el volume group

# vgcreate testvg /dev/vdb1

Luego creamos en Logical Volume

# lvcreate -n testlv testvg -L 5Gb

Una vez que tenemos el logical volume procedemos a encriptar el volumen con la clave que elijamos

# cryptosetup luksFormat /dev/testvg/testlv

Luego abrimos el volumen encriptado asignándole un alias, en este caso (testcrypt)

# cryptsetup luksOpen /dev/testvg/testlv testcrypt

Esto creara un alias con la ruta /dev/mapper/testcrypt, procedemos a formatear la particion

# mkfs.ext4 /dev/mapper/testcrypt

En caso de necesitar que el volumen se monte automaticamente debemos crear un archivo key donde escribiremos el password que elegimos.

# echo “passphrase” >> /root/test.key

# chmod 600 /root/test.key

Luego agregamos el key

# cryptsetup luksAddKey /dev/mapper/testcrypt /root/test.key

Luego debemos agregar los parametros de “alias” “volume” “key” al archivo /etc/crypttab

en este caso:

# testcrypt /dev/testvg/testlv /root/test.key

Luego agregamos el volumen al fstab, la mejor practica seria agregandole por el UUID del volumen, para obtener el UUID se debe ejecutar el siguiente comando

# blkid /dev/mapper/testcrypt

Agregamos los datos al fstab quedando de la siguiente manera (en este caso el volumen se montara en el /house)

UUID=3fe8804d-0b9f-4f18-af83-c64b9212cde5 / ext4 defaults 1 1
UUID=fd8a42ee-4832-4609-ad68-f9f6cf5d3e6d /boot ext4 defaults 1 2
UUID=3dc9b84c-6a32-4ee0-a0dc-1e9272672816 /home ext4 defaults 1 2
UUID=d24d46af-a504-46a4-9a69-c633d24c9501 /house ext4 defaults 1 2
UUID=b96943fc-8dee-4cbd-9c2b-3024a4232946 swap swap defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0

Migrar discos RDM a VMFS VSphere 5.5

Migrar discos RDM a VMFS

En caso de tener un cluster con discos compartidos RDM, los cuales queremos migrar a VMFS lo podemos hacer sin tener tanto downtime.

Se deben seguir los siguientes pasos:

  • Apagar nodo inactivo y configurarlo para usar VMFS como disco compartido
  • Prender el nodo inactivo y luego hacer switch-over de los servicios al mismo, de manera a liberar el otro nodo
  • Apagar el otro nodo y configurarlo para usar VMFS como disco compartido, dejar el equipo apagado
  • Eliminar el disco RDM del nodo que quedo apagado.
  • Bajar los servicios en el asusisv-pm2, eliminar el disco RDM y eliminar el archivo de referencia.
  • Volver a agregar el disco RDM con compatibilidad Virtual
  • La SCSI Controller debe ser Paravirtual
  • Levantar los servicios
  • Migrar los discos RDM a discos sobre VMFS del tipo Thick Provision Eager Zero
  • Levantar el otro nodo y probar que todo es funcionando correctamente

En este caso tendremos el siguiente entorno:

Cantidad de nodos del Cluster: 2
Sistema Operativo de los nodos: CentOS 7.0 x86_64
Version del virtualizador: VMWARE esx5.5
Herramienta administrativa: vSphere Web Client
Servicio de Cluster: Pacemaker
Modo del Cluster: Activo/Pasivo
Nombres de host: asusisv-pm1 y asusisv-pm2
Los servicios se estan ejecutando en el asusisv-pm1

Preparar nodo inactivo.

Apagar nodo inactivo

Primero debemos apagar el nodo que este inactivo, en este caso el asusisv-pm2

[root@asusisv-pm2 ~]# poweroff
Connection to asusisv-pm2 closed by remote host.
Connection to asusisv-pm2 closed.
Configurar VM para usar VMFS como disco compartido

Cambiar el Bus Sharing Controladora SCSI

Una vez que apagamos el equipo debemos asegurarnos que las controladoras SCSI donde estaran los discos compartidos esten en modo virtual.
Vamos a "Edit VM setting" -> "SCSI Controller 1", debemos asegurarnos que este en modo Virtual, es decir "SCSI Bus Sharing = Virtual"

Agregar Parametros a la VM

Para utilizar discos sobre VMFS como compartidos entre 2 o mas VMs es necesario modificar ciertos parametros en cada VM, los parametros son los siguientes:

  • disk.locking = false
  • scsi1:0.sharing = multi-writer
  • scsi1:0.shared = true

En el caso de los ultimos 2 parametros se debe agregar por cada disco que querramos compartir, por ejemplo si queremos compartir el disco 4 de la controladora scsi 3, deberiamos agregar los siguientes parametros:

scsi3:4.sharing = multi-writer
scsi3:4.shared = true

Esta tarea la podemos ingresando a "Edit VM setting" -> "VM Options" -> "Advanced" -> "Edit Configuration"

Una vez en la ventana de configuracion de parametros hacemos click en "Add row" y ingresamos cada parametro.

En nuestro caso nuestra controladora SCSI es la numero 2 y usaremos el disco 0, es recomendable agregar mas entradas de las que necesitamos para en el futuro poder agregar discos virtuales sin problemas, debido a que es necesario que la VM este apagada para modificar o agregar estos parametros, en nuestro ejemplo agregaremos lo siguiente:

disk.locking=false
scsi1:0.sharing = multi-writer
scsi1:0.shared = true
scsi1:1.sharing = multi-writer
scsi1:1.shared = true
scsi1:2.sharing = multi-writer
scsi1:2.shared = true
scsi1:3.sharing = multi-writer
scsi1:3.shared = true

Luego le damos en "OK", esperamos a que aplique los cambios y procedemos a prender la VM.

Preparar nodo activo

Una vez que culminamos las configuraciones del nodo inactivo debemos hacer switch-over de los servicios de manera a poder apagar el nodo activo, en este caso el asusisv-pm1.

Apagamos el equipo

[root@asusisv-pm1 ~]# poweroff
Connection to asusisv-pm1 closed by remote host.
Connection to asusisv-pm1 closed.

Una vez que el equipo este apagado debemos realizar la misma tarea que se realizo con el otro nodo.

Configurar VM para usar VMFS como disco compartido

Cambiar el Bus Sharing Controladora SCSI

Una vez que apagamos el equipo debemos asegurarnos que la controladora SCSI donde estan los discos compartidos este en modo virtual

Vamos a "Edit VM setting" -> "SCSI Controller 1", debemos verificar que este en modo Virtual, es decir SCSI Bus Sharing = Virtual

Agregar Parametros a la VM

Esta tarea la podemos ingresando a "Edit VM setting" -> "VM Options" -> "Advanced" -> "Edit Configuration"

Una vez en la ventana de configuracion de parametros hacemos click en "Add row" y ingresamos cada parametro.

En nuestro caso nuestra controladora SCSI es la numero 2 y usaremos el disco 0, es recomendable agregar mas entradas de las que necesitamos para en el futuro poder agregar discos virtuales sin problemas, debido a que es necesario que la VM este apagada para modificar o agregar estos parametros, en nuestro ejemplo agregaremos lo siguiente (el orden de los parametros no afecta):

disk.locking=false
scsi1:0.sharing = multi-writer
scsi1:0.shared = true
scsi1:1.sharing = multi-writer
scsi1:1.shared = true
scsi1:2.sharing = multi-writer
scsi1:2.shared = true
scsi1:3.sharing = multi-writer
scsi1:3.shared = true

Luego le damos en "OK".

Luego debemos eliminar el disco RDM del equipo, sin eliminar el archivo de referencia, esperamos a que aplique los cambios dejamos apagada la VM.

Migrar de RDM a VMFS

Sacar y volver a agregar el disco RDM

Desde el vSphere Web Client debemos buscar nuestra VM, en este caso asusisv-pm2, hacemos click derecho sobre el nombre luego hacemos click en Edit Settings, luego eliminamos el disco RDM, eliminando el archivo de referencia del Datastore. Esto lo podemos hacer con la maquina encendida pero debemos asegurarnos de que ningun servicio acceda al disco.

Luego debemos volver a agregar el disco RDM pero con compatibilidad Virtual.

Vamos a New device -> RDM -> Add y seleccionamos la lun que deseamos migrar.

Elegimos la lun

Al agregar el RDM debemos asegurarnos de que el Compatibility Mode este en Virtual y que el SCSI Controller este en uno de los configurados en los pasos previos.

Migracion de datos

Luego volver a hacer click derecho sobre nuestra maquina virtual y hacemos click en Migrate.

En la ventana "Select Migration Type", debemos seleccionar "Change datastore", luego le damos Next

En la ventana de Select Datastore, hacemos click en Advanced >>. Luego en la columna disk format de nuestro disco RDM debemos cambiar a Thick Provision Eager Zero, en la columna de Storage debemos seleccionar el Datastore donde queremos guardar el disco compartido, el datastore debe ser diferente de donde estaba el archivo de referencia, caso contrario no hace nada.

Le damos Next y confirmamos la tarea. Una vez que termine la tarea podemos agregar el disco virtual al otro nodo y luego prenderlo

Agregar el disco ya migrado al otro nodo

Luego de culminar la migracion vamos al otro nodo que habia quedado apagado, le damos Edit settings, luego en New device, elegimos Existing disk, luego al hacer click en Add nos mostrara una ventana en la cual debemos navegar dentro del DataStore hasta encontrar el disco virtual.

Si no recordamos la ubicacion del disco virtual podemos fijarnos en la lista de eventos del nodo desde el cual lanzamos la migracion, en este caso el asusisv-pm2, vamos a la VM y hacemos click, luego en Monitor -> Events. En la tarea de migracion dice el nombre del datastore, el disco en este caso se encontrara en un directorio llamado asusisv-pm2 dentro de dicho datastore.

Al agregar el disco debemos asegurarnos de que este en la SCSI Controller que configuramos en los primeros pasos.

Luego aplicamos y prendemos la maquina virtual.

Se recomienda probar hacer switch-over para probar que los 2 nodos puedan acceder sin problemas al disco

Una vez que se culminaron todos estos pasos y de que hayamos verificado que todo funcione correctamente podemos despresentar la LUN que antes se usaba como RDM

Instalar y configurar OpenGTS en CentOS/RHEL/SL 7

Instalar OpenGTS en CentOS/RHEL/SL 7

En este caso instalaremos el OpenGTS en un servidor CentOS 7, para esto es necesario configurar una base de datos MySQL/MariaDB

Pre-Requisitos

Antes de comenzar la instalacion es necesario instalar un par de paquetes, tarea que la haremos con yum:

yum install -y wget curl unzip ant

Instalar y configurar la base de datos

La primera tarea que realizaremos es la de instalar y configurar el motor de base de datos:

Instalar MySQL/MariaDB
yum install -y mariadb mariadb-server
Configurar el usuario de base de datos para OpenGTS

Primero debemos iniciar el servicio

systemctl start mariadb

Establecemos el password del usuario root de la base de datos con el comando mysql_secure_installation, respondemos las preguntas copiadas mas abajo y donde dice New Password: y Re-enter new password: ingresamos el nuevo password de root, en este caso pondremos '123456'

[root@opengts ~]# mysql_secure_installation
....
Set root password? [Y/n] Y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
 ... Success!
....
Remove anonymous users? [Y/n] Y
 ... Success!
....
Disallow root login remotely? [Y/n] n
 ... skipping.
....
Remove test database and access to it? [Y/n] Y
 - Dropping test database...
 ... Success!
 - Removing privileges on test database...
 ... Success!
....
Reload privilege tables now? [Y/n] Y
 ... Success!
....
Cleaning up...

Creamos el usuario de base de datos, en este caso el usuario es 'opengts' y el password 'opengts', para esto ingresamos a la consola del mysql con el usuario root :

mysql -u root -p123456

Y luego ejecutamos lo siguiente:

CREATE USER 'opengts'@'%' IDENTIFIED BY 'opengts';
GRANT ALL ON *.* TO 'opengts'@'%' IDENTIFIED BY 'opengts';
FLUSH PRIVILEGES;

Ejemplo:

[root@opengts ~]# mysql -u root -p123456
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 5.5.50-MariaDB MariaDB Server
 
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
MariaDB [(none)]>  CREATE USER 'opengts'@'%' IDENTIFIED BY 'opengts';
Query OK, 0 rows affected (0.00 sec)
 
MariaDB [(none)]>  GRANT ALL ON *.* TO 'opengts'@'%' IDENTIFIED BY 'opengts';
Query OK, 0 rows affected (0.01 sec)
 
MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
 
MariaDB [(none)]> exit
Bye

Finalmente habilitamos el servicio para que inicie cada vez que prendemos nuestro equipo

systemctl enable mariadb

Java

Instalar y configurar Java

Primero debemos instalar el paquete de java openjdk en la version 1.7:

yum install -y java-1.7.0-openjdk.x86_64

Es muy probable que no responda de que ya se encuentre instalado ya que es una de las dependencias del paquete ant
Luego establecemos la variable de entorno JAVA_HOME, primero la cargamos en el archivo /etc/bashrc para que se cargue para cualquier usuario que se conecte y luego la cargamos en memoria con el comando export

echo "export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk" >> /etc/bashrc
export JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk

Instalar las librerias necesarias

Luego de tener configurado nuestro java es necesario descargar las librerias que utiliza OpenGTS.

Descargamos la libreria javax-mail

wget -c https://maven.java.net/content/repositories/releases/com/sun/mail/javax.mail/1.5.2/javax.mail-1.5.2.jar

Luego ubicamos el archivo descargado en la carpeta de librerias de Java

mv javax.mail-1.5.2.jar $JAVA_HOME/jre/lib/ext/javax.mail.jar

Luego debemos descargar la libreria encargada de la conexion a la base de datos MariaDB:

wget -c http://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-5.1.37.zip

Luego descomprimimos

unzip mysql-connector-java-5.1.37.zip

Y finalmente copiamos el .jar a la carpeta de librerias de javayum

cp mysql-connector-java-5.1.37/mysql-connector-java-5.1.37-bin.jar $JAVA_HOME/jre/lib/ext

Tomcat

Debemos descargar la ultima version disponible de tomcat 7, en este caso lo haremos con el siguiente comando:

wget www-us.apache.org/dist/tomcat/tomcat-7/v7.0.70/bin/apache-tomcat-7.0.70.zip

Luego debemos descomprimir el tomcat y copiarlo al directorio /usr/local

unzip apache-tomcat-7.0.70.zip
cp -a apache-tomcat-7.0.70 /usr/local/tomcat

Apuntamos la variable CATALINA_HOME al directorio donde copiamos nuestro tomcat-7

echo "export CATALINA_HOME=/usr/local/tomcat/" >> /etc/bashrc
export CATALINA_HOME=/usr/local/tomcat/

Luego damos permisos de ejecucion a los scripts del tomcat

chmod a+x $CATALINA_HOME/bin/*.sh

OpenGTS

Instalar OpenGTS

Debemos descargar OpenGTS, lo mismo lo podemos hacer con el siguiente comando:

wget http://sourceforge.net/projects/opengts/files/server-base/2.6.0/OpenGTS_2.6.0.zip

Extraemos lo descargado dentro del directorio /usr/local

unzip OpenGTS_2.6.0.zip -d /usr/local

Luego debemos de establecer la variable de entorno GTS_HOME apuntando a nuestra instalacion de OpenGTS:

echo "export GTS_HOME=/usr/local/OpenGTS_2.6.0" >> /etc/bashrc
export GTS_HOME=/usr/local/OpenGTS_2.6.0

Debemos cargar los parametros de usuario y password de base de datos en la configuracion de OpenGTS, para esto editamos el archivo de configuracion con el comando vi:

vi $GTS_HOME/config.conf

Buscamos las lineas que digan db.sql.user=gts y db.sql.user=opengts, dichas lineas estan comentadas y deberian ser la linea numero 40 y 41 aproximadamente, debemos establecer los valores de usuario y password que seteamos en el MariaDB, en nuestro caso, opengts y opengts

...
db.sql.user=opengts
db.sql.password=opengts
...

Antes de compilar debemos de establecer la variable de entorno ANT_HOME:

echo "export ANT_HOME=/usr/share/ant" >> /etc/bashrc
export ANT_HOME=/usr/share/ant

Luego procedemos a compilar nuestro OpenGTS_2

cd $GTS_HOME 
ant all

Los comandos anteriores mostrarian en pantalla todo el proceso de compilacion y al final deberia devolver algo parecido a lo siguiente:

...
all:
     [echo] Build 'all' complete.
 
BUILD SUCCESSFUL
Total time: 31 seconds

Luego debemos inicializar la base de datos de OpenGTS, para hacer esto necesitamos pasarle como parametro el password de root que habiamos establecido, en nuestro caso 123456

$GTS_HOME/bin/initdb.sh -rootUser=root -rootPass=123456

Al final El comando deberia de mostrar algo parecido a lo siguiente:

---------------------------------------------------------------------------
Column validation completed successfully.
---------------------------------------------------------------------------
 
Updating GTS Version: 2.6.0
Updating DMTP Version: 1.3.6

Luego debemos crear una cuenta para acceder a nuestro OpenGTS, en este caso crearemos el usuario admin que tenga como password admin

$GTS_HOME/bin/admin.sh Account -account=admin -pass=admin -create

Debemos instalar el java servlet track

cd $GTS_HOME
ant track

Y lo debemos copiar al directorio webapp de nuestro tomcat:

cp $GTS_HOME/build/track.war $CATALINA_HOME/webapps/

Pasos finales

Finalmente debemos de configurar el servicio tomcat, de manera a que pueda iniciarse cada vez que se reinicie el equipo.

Debemos crear la definicion del servicio tomcat, lo cual lo hacemos con el siguiente comando:

cat <<EOF >/etc/systemd/system/tomcat.service
# Systemd unit file for tomcat
[Unit]
Description=Apache Tomcat Web Application Container
After=syslog.target network.target
 
[Service]
Type=forking
 
ExecStart=/usr/local/tomcat/bin/startup.sh
ExecStop=/usr/local/tomcat/bin/shutdown.sh
 
[Install]
WantedBy=multi-user.target
EOF

Luego iniciamos y habilitamos el servicio tomcat

systemctl enable tomcat
systemctl start tomcat

En caso de tener habilitado el firewall debemos permitir conexiones al puerto 8080:

firewall-cmd --add-port=8080/tcp --permanent  
firewall-cmd --reload

Para usar nuestro OpenGTS debemos acceder via navegar a la siguiente url http://ipdenuestroservidor:8080/track/Track, si la ip de nuestro servidor fuese 10.100.1.100 entonces la url seria: http://10.100.1.100:8080/track/Track

Configurar fence oVirt/RHEVM para Pacemaker

Configurar fence oVirt/RHEVM para Pacemaker

Para implementar fence sobre oVirt o RHEVM dentro del paquete fence-agents-all viene incluido el fence_rhevm el cual sirve tanto para oVirt como para RHEVM y su configuracion es bastante sencilla, solo necesitamos un usuario con permisos sobre nuestras maquinas virtuales.

Para obtener mas informacion sobre el fence agent que utilizaremos pueden ejecutar pcs stonith describe fence_rhevm dicho comando trae la informacion de todos los parametros que acepta el mismo y muestra cuales son requeridos.

En este ejemplo creamos un recurso fence para un equipo llamado av-app1, para el fence utilizaremos el usario user que tiene como password pass

La sintaxis es la siguiente:

 
pcs stonith create nombre_del_fence fence_rhevm shell_timeout=180 ssl_insecure=true ssl=true port=nombre_de_la_VM ipaddr=fqdn_de_nuestro_ovirt passwd=password_del_usuario action=reboot login=nombre_del_usuario pcmk_host_list=nombredelavm

Ej.:

pcs stonith create fence_av-app1 fence_rhevm shell_timeout=180 ssl_insecure=true ssl=true port=av-app1 ipaddr=ovirt.infratic.com passwd=pass action=reboot login=user pcmk_host_list=av-app1

Finalmente desde el otro nodo podemos probar si el fence funciona con el comando:

pcs stonith fence av-app1

Tengan en cuenta que el comando anterior reinicia la VM, por lo tanto tengan mucho cuidado al ejecutarlo