Skip to content

Resumen Postgresql

PostgreSQL Logo
PostgreSQL Logo

PostgreSQL

Postgresql creado en la Universidad de Berkley, es un sistema gestor de bases de datos relacional, que utiliza el puerto 5432 para su comunicación con los sistemas.

Los podemos descargar desde aquí, instalación que recomiendo pese a estar en los repositorios de Ubuntu.

Su usuario principal es postgres, del cuál nos pedirá una contraseña durante la instalación.

Tenemos varios programas para utilizar postgres:

  • En modo terminal psql
  • En modo gráfico pgadminIII
  • En modo web pgpadmin

Para trabajar en modo terminal deberemos acudir a la carpeta donde están los archivos binarios del sistema gestor de bases de datos en este caso:

  • /opt/PostgresSQL/9.3/bin

Una vez situados allí, tenemos acceso a todos los archivos ejecutables de Postgres, ahora solo nos falta cambiar de usuario, estos binarios únicamente los puede ejecutar el usuario “postgres”

Crear una base de datos

./createdb Nombre_base_datos

Entrar en la base de datos

./psql Nombre_base_datos

Crear tablas

CREATE TABLE nombre_tabla (

nombrecampo tipo restriccionescampo,

nombrecampo2 tipo restriccionescampo);

Borrar y modificar tablas

DROP TABLE nombre_tabla; (para crear)

ALTER TABLE nombre_tabla; (para modificar)

El prompt de postgres

Cuando el prompt se muestre con un igual (=) esto querrá decir que la sentencia que hemos introducido estará acabada, pero si nos muestra un guión (-) el prompt nos esta diciendo que la sentencia no esta acabada.

Creando restricciones

Clave primaria:

  • constraint persona_pk primary key (dni);

Clave foránea:

  • constraint dept2pers_fk foreign key (boss) REFERENCES persona (dni);

Como importar y exportar bases de datos.

Importar

En muchas bases de datos tendremos abrazadas mortales, por el momento sabemos que hay de varios tipos y que pueden ser muy habituales, para proceder de una manera correcta lo haremos de la siguiente manera, tendremos dos archivos por un lado las sentencias SQL que nos crean las tablas y las restricciones y por otro lado los datos.

  1. Primero abrimos el archivo que nos crea las tablas y restricciones con un editor de texto, de este separemos las creación de las tablas y los campos de las restricciones, algo que no será muy díficil ya que las restricciones siempre están al final del archivo, normalmente en formato SQL.
  2. Una vez hayamos separado esto último en dos archivos, utilizaremos únicamente el de la creación de tablas y campos y procederemos a la recuperación de la base de datos.
    1. ./psql base_datos < archivo_creador_tablas_y_campos.sql
  3. Ahora haremos los mismo con los datos, No con el archivo de restricciones resultante de la edición del paso 1!!.
    1. ./psql base_datos < archivo_con_datos.sql
  4. Cuando ya tengamos nuestra base de datos con las tablas y sus campos, y con todos los datos introducidos podemos pasar a la introducción de las restricciones.
    1. ./psql base_datos < archivo_con_restricciones.sql

Ya habremos recuperado nuestra base de datos con todos sus restricciones.

Exportar

De momento conoceremos la manera sencilla de exportación que no es más que realizar una copia de la base de datos entera, con tablas, campos, restricciones y datos.

./pg_dump base_datos > /home/usuario/fichero_backup.sql

Solo el esquema ./pg_dump -s base_datos > /home/usuario/fichero_backup_schema.sql

Solo los datos ./pg_dump -a base_datos > /home/usuario/fichero_backup_datos.sql

Backup all database
/usr/pgsql-10/bin/pg_dumpall -U postgres -h 127.0.0.1 -w > /tmp/postgresql_backup.sql
Restore all database
psql -f db.out postgres

Realizar consultas SQL

Todas las consultas SQL tienen el mismo formato:

SELECT – lista de campos (campo1,campo2,campo3)

AS – Alias para los campos

FROM – tablas a las que accedemos (también podemos utilizar alias para las tablas, tablaraul r, donde r sería el alias)

WHERE – Condiciones

Ejemplo consulta SQL

SELECT nom_regio AS regio, nom_pais AS pais

FROM public.region r, public.pais p

WHERE r.idregio = p.idpais;

SELECT nom_departament AS dpto, nom |’_’| cognoms AS cap

FROM departaments d, empleats e

WHERE d.idcap = e.idempleat;

Queremos conocer los datos de los empleados cuyo nombre  es Ferran

SELECT *

FROM empleats

WHERE nom LIKE ‘Ferran’; (LIKE) Solo con varchar, realizar búsquedas más finas

o

WHERE nom LIKE ‘f%’; % es un comodín para las búsquedas, nos dará los datos de todos los empleados que empieza su nombre por F

Quiero que me liste los atributos de los empleados cuyo nombre es formado por 4 letras

SELECT *

FROM empleats

WHERE nom LIKE ‘____’; (_ ) Comodín para el cáracter

Quiero saber todos los datos de las personas que cobren entre 1000€ y 2000€

SELECT *

FROM personas

WHERE sou Between 1000 AND 2000;

o

WHERE sou>=1000 AND sou<=2000;

Mongo DB / Administración

Mongo Db Logo
Mongo Db Logo

Importar de Json a MongoDB

sudo ./mongoimport –db actitvitat1 –collection people < ../data/db/persons.json

Crear sentencias Mongo

  1. Ens connectem al servidor mongo a la base de dades activitat1
    sudo ./mongo localhost/activitat1
  2. Mostrem tot el contingut de la col·lecció people
    db.people.find()
  3. Mostrem tot el contingut de la col·lecció people d’una manera més llegible.
    db.people.find().toArray()
  4. Mostrem les persones de 34 anys d’una manera llegible
    db.people.find({age:34}).toArray()
  5. Mostrem les persones de 34 anys i que siguin actius.
    db.people.find({age:34,isActive:true}).toArray()
  6. Mostrem el nom, l’edat i si són actius de les persones de 34 anys que siguin actius.
    db.people.find({age:34,isActive:true,{name:1,age:1}}).toArray()
  7. Mostrem el nom, l’edat i si són actius de les persones de 34 anys que siguin actius però desactivant el camp _id de la projecció.
    db.people.find({age:34,isActive:true},{name:1,age:1,_id:0}).toArray()
  8. Mostra una persona que compleixi els requeriments anteriors.
    db.people.find({age:34,isActive:true},{name:1,age:1,_id:0}).limit(1)
  9. Mostrem el nom i la edat de les persones que tenen més de 30 anys
    db.people.find({age:{$gte:30}}).toArray()
  10. Mostrem el nom i la edat de les persones que tenen 30 o més anys
    db.people.find({age:{$gte:30}},{name:1,age:1,_id:0}).toArray()
  11. Mostrem el nom i la edat de les persones menors de 30 anys
    db.people.find({age:{$lt:30}},{name:1,age:1,_id:0}).toArray()
  12. Mostrem el nom i la edat de les persones que no tenen 30 anys
    db.people.find({age:{$ne:30}},{name:1,age:1,_id:0}).toArray()
  13. Mostrem el nom i la edat de les persones que tenen 25, 30 o 35 anys
    db.people.find({age:{$in:[25,30,35]}},{name:1,age:1,_id:0}).toArray()
  14. Busquem els documents el camp gender sigui «female» i el camp age sigui més gran que 20.
    db.people.find({age:{$gte:30},gender:”female”},{name:1,age:1,_id:0}).toArray()
  15. Busquem els documents el camp gender sigui «female» o el camp age sigui més gran que 20
    db.people.find({$or:[{age:{$gte:30}},{gender:»female»}]},{name:1,age:1,_id:0}).toArray()
  16. Busquem els documents el camp gender sigui «female» i el camp age sigui més gran que 20 utilitzant l’operador $and.
    db.people.find({$and:[{age:{$gte:30}},{gender:»female»}]},{name:1,age:1,_id:0}).toArray()
  17. Busca les persones a people en que la seva edat és més gran que 30, o el gènere és «female» i la seva edat més gran que 50.
    db.people.find({$or:[{age:{$gte:30}},{$and:[{gender:»female»,age:50}]}]},{name:1,age:1,_id:0}).toArray()
  18. Busquem les persones edat NO sigui més gran que 30 i el camp isActive NO sigui true.
    db.peole.find({$and:[{age:{$lt:30}},{isActive:false}]})
  19. Busca l’element «laborum» a l’array tags, retornant les persones en el que en aquest array existeixi aquest element
    db.peole.find({$and:[{age:{$lt:30}},{isActive:false}]})
  20. Volem trobar totes les persones que continguin en tags els valors laborum i sunt.
    db.people.find({$and:[{tags:»laborum»},{tags:»sunt»}]}).toArray()
  21. Volem trobar totes les persones que continguin en tags alguns dels valors laborum, sunt, nisi
    db.people.find({tags:{$all:[«laborum»,»sunt»,»nisi»]}}).toArray()
  22. Volem trobar totes les persones que NO continguin a l’array tags alguns dels valors especificats: laborum, sunt i, nisi
  23. Retornar tots els documents on l’array tags té una mida de 3 elements
  1. Volem trobar totes les persones que continguin en tags alguns dels valors laborum, sunt, nisi
    db.people.find({tags:{$all:[«laborum»,»sunt»,»nisi»]}}).toArray()

Leer Sentencias Mongo

  1. db.people.find({«friends.2.name»:{$gte:»T»}}).count()
    Cuenta las per
  2. db.people.find({«friends.2.name»:{$gte:»T»}},{_id:0,name:1}).sort({name:1})
  3. db.people.find({«friends.2.name»:{$gte:»T»}},{_id:0,name:1}).sort({name: -1})
  4. db.people.find({«friends.2.name»:{$gte:»T»}},{_id:0,name:1,email:1}).sort({name:1,email:1})
  5. db.people.find({«friends.2.name»:{$gte:»T»}},{name:1}).limit(5)
  6. db.people.find({«friends.2.name»:{$gte:»T»}},{name:1}).skip(5)
  7. var myArray = db.people.find({«friends.2.name»:{$gte:»T»}},{name:1}).toArray()
  8. db.people.find({«friends.2.name»:{$gte:»T»}},{name:1}).skip(10).limit(5)
  9. db.people.find({«friends.2.name»:{$gte:»T»}}, {name:1}).sort({name:1}).limit(1)

Backup

Coger todos las bases de datos de mongo

  • mongo –eval db.getMongo().getDBNames().join(‘\n’) –quiet

Con Usuario

  • mongo –authenticationDatabase MONGO_DB_AUTH –username Mongo_User –password Mongo_Pass –eval db.getMongo().getDBNames().join(\n) –quiet

Ya tenemos en nuestra variable de bash todas las db que tenemos activadas en mongo, vamos a obtener las colecciones

  • mongo –eval db.getCollectionNames().join(‘\n’) –quiet

Con Usuario

  • mongo –authenticationDatabase MONGO_DB_AUTH –username Mongo_User –password Mongo_Pass –eval db.getCollectionNames().join(‘\n’) –quiet

Backup de la BD entera

  • mongodump –db NAME_DB –host localhost –out PATH_BACKUP

Con Usuario

  • mongodump –authenticationDatabase $MONGO_AUTH_DB –username $MONGO_USER –password $MONGO_PASS –db NAME –host localhost –out PATH_BACKUP

Backup Colecciones

  • mongodump –db NAME_DB –collection NAME_COLLECTION –host localhost –archives=NOMBRE_DB.NOMBRE_COLLECTION.HORA.archive

Con Usuario

mongodump –authenticationDatabase $MONGO_AUTH_DB –username $MONGO_USER –password $MONGO_PASS db NAME_DB –collection NAME_COLLECTION –host localhost –archives=NOMBRE_DB.NOMBRE_COLLECTION.HORA.archive

Restore Backup

Recuperar un backup de colecciones Entramos dentro del directorio donde tenemos todas las colecciones:


for x in `ls`;
do
mongorestore –archive=$x –db NAME_DB –port 27017;
done

Base de Datos Cassandra / Administración

Cassandra Logo
Cassandra Logo

Terminología Cassandra

  • Node: Equipo donde se almacenan los datos.
  • Data Center: Una colección de nodos. Puede ser físico o virtual
  • Cluster: Un cluster contiene uno o más DataCenter.
  • Commit Log: Es un mecanismo de recuperación de fallos. Todos los datos se escriben primero en el registro de confirmación (archivo) para mayor durabilidad. Después de que todos sus datos se hayan enviado a SSTables, se pueden archivar, eliminar o reciclar.
  • Table: Colección de columnas ordenadas por filas.
  • SSTable: Una tabla de cadenas ordenadas (SSTable) es un archivo de datos inmutables en el que Cassandra escribe los archivos de forma periódica. Los SSTables se agregan solo y se almacenan en el disco secuencialmente y se mantienen para cada tabla de Cassandra.
  • Gossip: Gossip es un protocolo de comunicación de igual a igual en el que los nodos intercambian periódicamente información de estado sobre ellos mismos y sobre otros nodos que conocen. El proceso de chismes se ejecuta cada segundo e intercambia mensajes de estado con hasta tres nodos más en el clúster.
  • Bloom Filter: son algoritmos rápidos, no deterministas, para probar si un elemento es miembro de un conjunto. Se accede a los filtros Bloom después de cada consulta.

Como escribe Cassandra los datos

Los procesos de escritura de Cassandra siguen unos pasos muy estrictos:

  1. Escritura de la operación de inserción de datos en el commit log.
  2. Escritura de los datos en memtable
  3. Flushing de los datos desde memtable.
  4. Escritura en los discos en SSTable.

Configuraciones recomendadas

Máquina Virtual de JAVA

Sincronización de los relojes internos

Configuraciones TCP

Durante intervalos de poco tráfico, el servidor puede cerrar las conexiones tanto entre nodos locales como en nodos externos, esto lo hace por el tiempo de espera de conexión inactiva que esté configurado. Para solucionarlo:
sysctl -w \
net.ipv4.tcp_keepalive_time=60 \
net.ipv4.tcp_keepalive_probes=3 \
net.ipv4.tcp_keepalive_intvl=10

Esta configuración mantiene viva la conexión durante 60 segundos con 3 intentos y con 10 segundos entre cada intento.

Si debemos manejar miles de conexiones simultáneas que usará la base de datos, debemos cambiar esta configuración en el kernel:
sysctl -w \
net.core.rmem_max=16777216 \
net.core.wmem_max=16777216 \
net.core.rmem_default=16777216 \
net.core.wmem_default=16777216 \
net.core.optmem_max=40960 \
net.ipv4.tcp_rmem=4096 87380 16777216 \
net.ipv4.tcp_wmem=4096 65536 16777216

Hay que asegurarse que los cambios persisten después de reiniciar

Desactivar CPU Frequency Scaling

Los sistemas linux incluyen una característica llamada CPU frequency scaling o CPU speed scaling. Esto permite a los servidores puedan funcionar a velocidades de reloj más baja cuando la demanda o carga sea baja.

  • Desafortunadamente, este comportamiento tiene un efecto perjudicial en los servidores que ejecutan Cassandra porque el rendimiento se puede limitar a un ritmo menor. Para garantizar un rendimiento óptimo, reconfiguramos todas las CPU para usar el regulador de rendimiento que bloquea la frecuencia al máximo. Este gobernador no cambiará las frecuencias, por lo tanto no habrá ahorro de energía y los servidores siempre se ejecutarán al máximo rendimiento, para configurar el gobernador:
    for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    do
    [ -f $CPUFREQ ] || continue
    echo -n performance > $CPUFREQ
    done

Optimize SSD’s

La mayoría de las configuraciones SSD en Linux no son óptimas.

  1. Asegurate que el SysFs rotational flag está en false.
  2. Aplicamos la misma marca de rotación para cualquier dispositivo de bloque creado desde el almacenamiento SSD, como mdarrays.
  3. Establecer el scheduler IO en fecha límite o noop.
    1. El programador de noop es la opción correcta cuando el dispositivo de bloque de destino es una matriz de SSD detrás de un controlador IO de gama alta que realiza la optimización de IO.
    2. El programador de la fecha límite optimiza las solicitudes para minimizar la latencia de IO. En caso de duda, utilice el programador de plazos.
  4. Establecer el readhead con valor de 8k.

Ejemplo en disco Sda
echo deadline > /sys/block/sda/queue/scheduler
#OR…
#echo noop > /sys/block/sda/queue/scheduler
touch /var/lock/subsys/local
echo 0 > /sys/class/block/sda/queue/rotational
echo 8 > /sys/class/block/sda/queue/read_ahead_kb

Use de optimum / RAID on SSD

Establecer el readhead con valor de 8k.

Disable zone_reclaim_mode

El kernel de Linux puede ser inconsistente en habilitar/deshabilitar la zone_reclaim_mode. Esto nos puede traer los siguientes problemas de rendimiento: A

  • Enormes picos aleatorios de CPU.
  • Programas colgados indefinidamente, aparentemente sin hacer nada.
  • Los síntomas aparecen y desaparecen de repente.
  • Después de un reinicio los síntomas generalmente no se muestran de nuevo durante un tiempo.

Desactivar la zone_reclaim_mode:
echo 0 > /proc/sys/vm/zone_reclaim_mode

Set user resource limits

Aunque los límites pueden ser temporales DataStax recomienda hacer los siguientes cambios permanentes: A
Package and Installer-Services:
/etc/security/limits.d/cassandra.conf
<cassandra_user> – memlock unlimited
<cassandra_user> – nofile 100000
<cassandra_user> – nproc 32768
<cassandra_user> – as unlimited

Tarball and Installer-No Services:
<cassandra_user> – memlock unlimited
<cassandra_user> – nofile 100000
<cassandra_user> – nproc 32768
<cassandra_user> – as unlimited

Run DataStax como root? Algunas distribuciones como ubuntu necesitan los pasar los límites que establecimos para el usuario cassandra a root.
root – memlock unlimited
root – nofile 100000
root – nproc 32768
root – as unlimited

Para RHEL 6.x-based systems, establecer también el nrpoc limits:
/etc/security/limits.d/90-nproc.conf
cassandra_user – nproc 32768

Para todas las instalaciones:
cassandra_user – nproc 32768
vm.max_map_count = 1048575

Para instalaciones de Debian o Ubuntu el módulo pam_limits.so no esta activado por defecto:
/etc/pam.d/su
session required pam_limits.so
sysctl -p para guardar los cambiar y activarlos. Después reiniciar el sistema para comprobar que los cambios siguen activos.

Disable Swap

Si no se desactiva el intercambio por completo, se puede ver reducido considerablemente el rendimiento. Debido a que la bd tiene múltiples réplicas y conmutación por error transparente, es preferible que un réplica se elimine inmediatamente cuando la memoria está baja en lugar de ir a la Swap. Esto permite que el tráfico se redirija inmediatamente a una réplica en funcionamiento en lugar de continuar intentado acceder a la réplica que tiene una latencia alta debido a encontrarse en la memoria swap. Mientras más memoria Swap mayor reducción de rendimiento.
swapoff -all (Cambio no permanente).
Eliminar partición swap del /etc/fstab (Cambio permanente).

Esta opción no nos convence mucho ya que dejaríamos al sistema sin memoria Swap. Para que Cassandra no utilice tanto o demasiado la memoria swap vamos a reducir el porcentaje swapinnes, diciéndole al sistema que utilice menos memoria Swap.

Para ver la configuración actual:
cat /proc/sys/vm/swappiness

Para cambiar:
/etc/sysctl.conf
vm.swapinness = 10

Check Java Hugespaces setting

Cuando linux usa Hugepages, el núcleo intenta asignar memoria en grandes porciones (2MB en lugar de 4K). Esto puede mejorar el rendimiento al reducir el ńumero de páginas que la CPU debe asignar. Sin embargo algunas aplicaciones todavía asignan memoria basada en 4K y esto puede causar problemas de rendimiento cuando linux intenta desfragmentar páginas de 2MB y sean de 4K. A

Para solucionarlo desactivamos el hugepages transparent.
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

Comandos útiles

Para encontrar el pid:
ps axu | grep cassandra

Para ver los puertos de escucha:
netstat -tulpn | grep -i listen | grep <pid>

Para conectar con la consola de cassandra
cqlsh ip_del_servidor -u cassandra -p cassandra

Insertar Datos para pruebas
cqlsh ip_nodo -u cassandra -p cassandra < file_inserts;

Refrescar una tabla
nodetool ip_nodo refresh adtech geosc

Rebuild (para replicar datacenters dentro de datacenters)
nodetool rebuild — dc1 o dc2, o el que sea
nodetool abortrebuild // para abortar la sincro entre data centers.

Estado de la tabla, desglose de campos del comando.
nodetool tablestats adtech.geosc

Obtener snapshot de todas las colecciones.
nodetool snapshot.

Limpiar los snapshot de todas las colecciones.
nodetool clearsnapshot

Simple flush memtables en disco.
nodetool flush

Escribe todas las memtables de un nodo con SSTables en disco.
nodetool drain
Cassandra para de escuchar más conexiones de los clientes y otros nodos. Es necesario reiniciar Cassandra después de utilizar nodetool drain. Normalmente usaremos este comando antes de upgradear un nodo a una nueva versión de cassandra.

Estado de cassandra utilizando la red
nodetool netstats

Estado del backup
nodetool statusbackup

Ver estado de las particiones y del cluster
nodetool describing
nodetool describecluster

Info de un nodo
nodetool status
De aquĺ podemos sacar el identificador que por ejemplo necesitamos en el siguiente comando.

Quitar un nodo
nodetool removenode ID

Export

Export schemas

Para conocer los esquemas instalados
SELECT keyspace_name, table_name from system_schema.tables;
SELECT * FROM system_schema.tables;

Para exportar todo los schemas:
cqlsh ip server usuario -p passwd -e «DESCRIBE SCHEMA» > /your/path/schema.cql

Para importar con el archivo de exportación antes obtenido
cqlsh ip server -u cassandra -p cassandra -f schema_adtech.cql

Export data

Para exportar datos Cassandra es capaz de crear un snapshot de los datos actualizados en caliente.

El comando:
nodetool snapshop

Este comando genera una snapshot por cada colección que haya sido creada en Cassandra. Nos devuelve un número que es la carpeta donde está todo el contenido a exportar.
/var/lib/data/adtech/users-213434513042342/snapshot/155489393/

Dentro de la última carpeta tenemos los misma db que en:
/var/lib/data/adtech/users-213434513042342/

Para borrar los snapshot y evitar la carga de disco del servidor de producción:
nodetool clearsnapshop

Importante: Sin el schema los datos no se verán en ningún sitio, es importante tener el backup del schema importado.

Una vez ya recuperado el schema veremos que tenemos las mismas carpetas que en el servidor a exportar, solo nos faltará descargar los datos del Servidor de backup y descomprimirlos en la carpeta correspondiente.

Para poder apreciar los datos debemos lanzar el comando:
nodetools refresh <basedatos> <tabla>

Import

Como ya tenemos preparado un snapshot diario (guardamos una semana) de cada nodo de cassandra, en caso de querer recuperar una tabla de la colección adtech, la única que se generó y se está guardando, solo deberemos acceder a Store y obtener la copia de los datos que ya tenemos. Para recuperar los datos debemos seguir los siguientes pasos:

  1. Para importar datos de un nodo debemos apagar el nodo donde queremos importar los datos

systemctl stop cassandra

  1. Una vez apagado, debemos eliminar los datos anteriores:

Eliminar datos de:
/var/lib/cassandra/data/adtech/geosc-numeroID/*.db

  1. Copiamos el interior del snapshot dentro de:

/var/lib/cassandra/data/adtech/geosc-numeroID/

  1. Encendemos cassandra y refrescamos la tabla.

systemctl start cassandra
nodetool refresh adtech.geosc

  1. Reiniciamos cassandra

systemctl restart cassandra

Para comprobar que todo ha ido bien:
Contamos las celdas donde cogimos el backup, realizamos estas sentencias tanto en el nodo donde exportamos los datos, como en el nodo donde importamos los datos
cqlsh nodo -u cassandra -p cassandra n
SELECT COUNT(*) FROM adtech.geosc;

Comando nodetool tablestats adtech geosc para obtener información de las tablas.

Eliminar un nodo

  1. Asegurarse de que el nodo esta UP/DOWN usando nodetool status (UN=up, DN=down):
  2. Si el nodo esta UP, ejecutar nodetool decommission (en el nodo que se va a dar de baja)

Nota: El decommision no para el servicio de cassandra, hace falta pararlo una vez haya terminado. El proceso tarda, según el tamaño del cluster de cassandra (ejecutar en un screen)

  1. Si el nodo está DOWN, ejecutar nodetool removenode <Host ID> (desde cualquiera de los demás nodos).
    1. Nota: el proceso tarda, según el tamaño del cluster de cassandra (ejecutar en un screen).
    2. Mucho ojo con el espacio en disco
  2. Si el removenode falla, ejecutar nodetool assassinate <IP Address> (desde cualquiera de los demás nodos).

Añadir un DataCenter

  • Con el “Cassandra” parado, “limpiar” posibles directorios de datos anteriores.

rm -rf /var/lib/cassandra/* <- OJO! No eliminar el directorio, únicamente el contenido.

  • Mientras se está “añadiendo” un nuevo Datacenter… es aconsejable que el cliente (los php’s del cliente), utilicen CONSISTENCY LOCAL_ONE, ó, LOCAL_QUORUM
  • Asegurarse que en Datacenter que está “UP”, está como NetworkTopologyStrategy… sinó es así, aplicar el siguiente “ALTER”:

ALTER KEYSPACE «sample_ks» WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘ExistingDC’ : 3 };

Revisar ficheros de configuración (añadir nombres, ips, etc… ):
/etc/cassandra/conf/cassandra.yaml

  • Añadir en el fichero “cassandra.yaml” una “seed” (la IP) en cada “Datacenter”. Ej. seeds: «217.13.124.41,94.24.114.104» ( 1 nodo del Datacenter1 y otro nodo del Datacenter 2)
  • Arrancar cada uno de los nuevos nodos del “nuevo Datacenter”
  • Añadir el nuevo Datacenter en los “keyspaces” del “antiguo Datacenter”. (hacerlo solo en 1 nodo).

ALTER KEYSPACE «sample_ks» WITH REPLICATION = {‘class’: ‘NetworkTopologyStrategy’, ‘ExistingDC’:3, ‘NewDC’:3};
Ej:
ALTER KEYSPACE system_distributed WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘dc1’ : 3, ‘dc2’ : 3 };
ALTER KEYSPACE system_traces WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘dc1’ : 3, ‘dc2’ : 3 };
ALTER KEYSPACE adtech WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘dc1’ : 3, ‘dc2’ : 3 };
ALTER KEYSPACE music WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘dc1’ : 3, ‘dc2’ : 3 };
Opcional (usuarios «globales»?):
ALTER KEYSPACE system_auth WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘dc1’ : 3, ‘dc2’ : 3 };

  • Comprobar, desde consola del Cassandra que todo está OK:

SELECT * FROM system_schema.keyspaces;

  • Hacer “sincronización inicial” en CADA UNO de los NODOS NUEVOS:

nodetool rebuild — dc1

Añadir un Nodo

Tenemos varias variables a tener en cuenta a la hora de añadir un nodo a cassandra.

  • Auto_bootstrap. Variable que solo hace falta en el primer arranque de cassandra. Importante borrar esta opción después de la primera arrancada.
  • cluster_name. Nombre del cluster donde la vamos a añadir
  • listen_address / broadcast_address. IP de escucha / Ip de comunicación con otros nodos.
  • seed_provider. Sacar el nodo que queremos añadir de las semillas.

Importante: Estaría bien tener una copia de la configuración antes de levantar nada. Ya que allí vemos de forma rápida donde debemos cambiar la IP o la opción que necesitemos.

Importante: Mucho ojo con esta conf: cassandra-topology.properties

Terminología Cassandra

  • Node: Equipo donde se almacenan los datos.
  • Data Center: Una colección de nodos. Puede ser físico o virtual
  • Cluster: Un cluster contiene uno o más DataCenter.
  • Commit Log: Es un mecanismo de recuperación de fallos. Todos los datos se escriben primero en el registro de confirmación (archivo) para mayor durabilidad. Después de que todos sus datos se hayan enviado a SSTables, se pueden archivar, eliminar o reciclar.
  • Table: Colección de columnas ordenadas por filas.
  • SSTable: Una tabla de cadenas ordenadas (SSTable) es un archivo de datos inmutables en el que Cassandra escribe los archivos de forma periódica. Los SSTables se agregan solo y se almacenan en el disco secuencialmente y se mantienen para cada tabla de Cassandra.
  • Gossip: Gossip es un protocolo de comunicación de igual a igual en el que los nodos intercambian periódicamente información de estado sobre ellos mismos y sobre otros nodos que conocen. El proceso de chismes se ejecuta cada segundo e intercambia mensajes de estado con hasta tres nodos más en el clúster.
  • Bloom Filter: son algoritmos rápidos, no deterministas, para probar si un elemento es miembro de un conjunto. Se accede a los filtros Bloom después de cada consulta.

Como escribe Cassandra los datos

Los procesos de escritura de Cassandra siguen unos pasos muy estrictos:

  1. Escritura de la operación de inserción de datos en el commit log.
  2. Escritura de los datos en memtable
  3. Flushing de los datos desde memtable.
  4. Escritura en los discos en SSTable.

Configuraciones recomendadas

Máquina Virtual de JAVA

Sincronización de los relojes internos

Configuraciones TCP

Durante intervalos de poco tráfico, el servidor puede cerrar las conexiones tanto entre nodos locales como en nodos externos, esto lo hace por el tiempo de espera de conexión inactiva que esté configurado. Para solucionarlo:
sysctl -w \
net.ipv4.tcp_keepalive_time=60 \
net.ipv4.tcp_keepalive_probes=3 \
net.ipv4.tcp_keepalive_intvl=10

Esta configuración mantiene viva la conexión durante 60 segundos con 3 intentos y con 10 segundos entre cada intento.

Si debemos manejar miles de conexiones simultáneas que usará la base de datos, debemos cambiar esta configuración en el kernel:
sysctl -w \
net.core.rmem_max=16777216 \
net.core.wmem_max=16777216 \
net.core.rmem_default=16777216 \
net.core.wmem_default=16777216 \
net.core.optmem_max=40960 \
net.ipv4.tcp_rmem=4096 87380 16777216 \
net.ipv4.tcp_wmem=4096 65536 16777216

Hay que asegurarse que los cambios persisten después de reiniciar

Desactivar CPU Frequency Scaling

Los sistemas linux incluyen una característica llamada CPU frequency scaling o CPU speed scaling. Esto permite a los servidores puedan funcionar a velocidades de reloj más baja cuando la demanda o carga sea baja.

Desafortunadamente, este comportamiento tiene un efecto perjudicial en los servidores que ejecutan Cassandra porque el rendimiento se puede limitar a un ritmo menor. Para garantizar un rendimiento óptimo, reconfiguramos todas las CPU para usar el regulador de rendimiento que bloquea la frecuencia al máximo. Este gobernador no cambiará las frecuencias, por lo tanto no habrá ahorro de energía y los servidores siempre se ejecutarán al máximo rendimiento, para configurar el gobernador:
for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
do
[ -f $CPUFREQ ] || continue
echo -n performance > $CPUFREQ
done

Optimize SSD’s

La mayoría de las configuraciones SSD en Linux no son óptimas.

  1. Asegurate que el SysFs rotational flag está en false.
  2. Aplicamos la misma marca de rotación para cualquier dispositivo de bloque creado desde el almacenamiento SSD, como mdarrays.
  3. Establecer el scheduler IO en fecha límite o noop.
    1. El programador de noop es la opción correcta cuando el dispositivo de bloque de destino es una matriz de SSD detrás de un controlador IO de gama alta que realiza la optimización de IO.
    2. El programador de la fecha límite optimiza las solicitudes para minimizar la latencia de IO. En caso de duda, utilice el programador de plazos.
  4. Establecer el readhead con valor de 8k.

Ejemplo en disco Sda
echo deadline > /sys/block/sda/queue/scheduler
#OR…
#echo noop > /sys/block/sda/queue/scheduler
touch /var/lock/subsys/local
echo 0 > /sys/class/block/sda/queue/rotational
echo 8 > /sys/class/block/sda/queue/read_ahead_kb

Use de optimum / RAID on SSD

Establecer el readhead con valor de 8k.

Disable zone_reclaim_mode

El kernel de Linux puede ser inconsistente en habilitar/deshabilitar la zone_reclaim_mode. Esto nos puede traer los siguientes problemas de rendimiento: A

  • Enormes picos aleatorios de CPU.
  • Programas colgados indefinidamente, aparentemente sin hacer nada.
  • Los síntomas aparecen y desaparecen de repente.
  • Después de un reinicio los síntomas generalmente no se muestran de nuevo durante un tiempo.

Desactivar la zone_reclaim_mode:
echo 0 > /proc/sys/vm/zone_reclaim_mode

Set user resource limits

Aunque los límites pueden ser temporales DataStax recomienda hacer los siguientes cambios permanentes: A
Package and Installer-Services:
/etc/security/limits.d/cassandra.conf
<cassandra_user> – memlock unlimited
<cassandra_user> – nofile 100000
<cassandra_user> – nproc 32768
<cassandra_user> – as unlimited

Tarball and Installer-No Services:
<cassandra_user> – memlock unlimited
<cassandra_user> – nofile 100000
<cassandra_user> – nproc 32768
<cassandra_user> – as unlimited

Run DataStax como root? Algunas distribuciones como ubuntu necesitan los pasar los límites que establecimos para el usuario cassandra a root.
root – memlock unlimited
root – nofile 100000
root – nproc 32768
root – as unlimited

Para RHEL 6.x-based systems, establecer también el nrpoc limits:
/etc/security/limits.d/90-nproc.conf
cassandra_user – nproc 32768

Para todas las instalaciones:
cassandra_user – nproc 32768
vm.max_map_count = 1048575

Para instalaciones de Debian o Ubuntu el módulo pam_limits.so no esta activado por defecto:
/etc/pam.d/su
session required pam_limits.so
sysctl -p para guardar los cambiar y activarlos. Después reiniciar el sistema para comprobar que los cambios siguen activos.

Disable Swap

Si no se desactiva el intercambio por completo, se puede ver reducido considerablemente el rendimiento. Debido a que la bd tiene múltiples réplicas y conmutación por error transparente, es preferible que un réplica se elimine inmediatamente cuando la memoria está baja en lugar de ir a la Swap. Esto permite que el tráfico se redirija inmediatamente a una réplica en funcionamiento en lugar de continuar intentado acceder a la réplica que tiene una latencia alta debido a encontrarse en la memoria swap. Mientras más memoria Swap mayor reducción de rendimiento.
swapoff -all (Cambio no permanente).
Eliminar partición swap del /etc/fstab (Cambio permanente).

Esta opción no nos convence mucho ya que dejaríamos al sistema sin memoria Swap. Para que Cassandra no utilice tanto o demasiado la memoria swap vamos a reducir el porcentaje swapinnes, diciéndole al sistema que utilice menos memoria Swap.

Para ver la configuración actual:
cat /proc/sys/vm/swappiness

Para cambiar:
/etc/sysctl.conf
vm.swapinness = 10

Check Java Hugespaces setting

Cuando linux usa Hugepages, el núcleo intenta asignar memoria en grandes porciones (2MB en lugar de 4K). Esto puede mejorar el rendimiento al reducir el ńumero de páginas que la CPU debe asignar. Sin embargo algunas aplicaciones todavía asignan memoria basada en 4K y esto puede causar problemas de rendimiento cuando linux intenta desfragmentar páginas de 2MB y sean de 4K. A

Para solucionarlo desactivamos el hugepages transparent.
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

Comandos útiles

Para encontrar el pid:

  • ps axu | grep cassandra

Para ver los puertos de escucha:

  • netstat -tulpn | grep -i listen | grep <pid>

Para conectar con la consola de cassandra

  • cqlsh ip_del_servidor -u cassandra -p cassandra

Insertar Datos para pruebas

  • cqlsh ip_nodo -u cassandra -p cassandra < file_inserts;

Refrescar una tabla

  • nodetool ip_nodo refresh adtech geosc

Rebuild (para replicar datacenters dentro de datacenters)

  • nodetool rebuild — dc1 o dc2, o el que sea
  • nodetool abortrebuild // para abortar la sincro entre data centers.

Estado de la tabla, desglose de campos del comando.

  • nodetool tablestats adtech.geosc

Obtener snapshot de todas las colecciones.

  • nodetool snapshot.

Limpiar los snapshot de todas las colecciones.

  • nodetool clearsnapshot

Simple flush memtables en disco.

  • nodetool flush

Escribe todas las memtables de un nodo con SSTables en disco.

  • nodetool drain

Cassandra para de escuchar más conexiones de los clientes y otros nodos. Es necesario reiniciar Cassandra después de utilizar nodetool drain. Normalmente usaremos este comando antes de upgradear un nodo a una nueva versión de cassandra.

Estado de cassandra utilizando la red

  • nodetool netstats

Estado del backup

  • nodetool statusbackup

Ver estado de las particiones y del cluster

  • nodetool describing
  • nodetool describecluster

Info de un nodo

  • nodetool status

De aquĺ podemos sacar el identificador que por ejemplo necesitamos en el siguiente comando.

Quitar un nodo

  • nodetool removenode ID

Export

Export schemas

Para conocer los esquemas instalados
SELECT keyspace_name, table_name from system_schema.tables;
SELECT * FROM system_schema.tables;

Para exportar todo los schemas:

  • cqlsh ip server usuario -p passwd -e «DESCRIBE SCHEMA» > /your/path/schema.cql

Para importar con el archivo de exportación antes obtenido
cqlsh ip server -u cassandra -p cassandra -f schema_adtech.cql

Export data

Para exportar datos Cassandra es capaz de crear un snapshot de los datos actualizados en caliente.

El comando:

  • nodetool snapshop

Este comando genera una snapshot por cada colección que haya sido creada en Cassandra. Nos devuelve un número que es la carpeta donde está todo el contenido a exportar.
/var/lib/data/adtech/users-213434513042342/snapshot/155489393/

Dentro de la última carpeta tenemos los misma db que en:
/var/lib/data/adtech/users-213434513042342/

Para borrar los snapshot y evitar la carga de disco del servidor de producción:

  • nodetool clearsnapshop

Importante: Sin el schema los datos no se verán en ningún sitio, es importante tener el backup del schema importado.

Una vez ya recuperado el schema veremos que tenemos las mismas carpetas que en el servidor a exportar, solo nos faltará descargar los datos del Servidor de backup y descomprimirlos en la carpeta correspondiente.

Para poder apreciar los datos debemos lanzar el comando:
nodetools refresh <basedatos> <tabla>

Import

Como ya tenemos preparado un snapshot diario (guardamos una semana) de cada nodo de cassandra, en caso de querer recuperar una tabla de la colección adtech, la única que se generó y se está guardando, solo deberemos acceder a Store y obtener la copia de los datos que ya tenemos. Para recuperar los datos debemos seguir los siguientes pasos:

  1. Para importar datos de un nodo debemos apagar el nodo donde queremos importar los datos

systemctl stop cassandra

  1. Una vez apagado, debemos eliminar los datos anteriores:

Eliminar datos de:
/var/lib/cassandra/data/adtech/geosc-numeroID/*.db

  1. Copiamos el interior del snapshot dentro de:

/var/lib/cassandra/data/adtech/geosc-numeroID/

  1. Encendemos cassandra y refrescamos la tabla.

systemctl start cassandra
nodetool refresh adtech.geosc

  1. Reiniciamos cassandra

systemctl restart cassandra

Para comprobar que todo ha ido bien:
Contamos las celdas donde cogimos el backup, realizamos estas sentencias tanto en el nodo donde exportamos los datos, como en el nodo donde importamos los datos
cqlsh nodo -u cassandra -p cassandra n
SELECT COUNT(*) FROM adtech.geosc;

Comando nodetool tablestats adtech geosc para obtener información de las tablas.

Eliminar un nodo

  1. Asegurarse de que el nodo esta UP/DOWN usando nodetool status (UN=up, DN=down):
  2. Si el nodo esta UP, ejecutar nodetool decommission (en el nodo que se va a dar de baja)

Nota: El decommision no para el servicio de cassandra, hace falta pararlo una vez haya terminado. El proceso tarda, según el tamaño del cluster de cassandra (ejecutar en un screen)

  1. Si el nodo está DOWN, ejecutar nodetool removenode <Host ID> (desde cualquiera de los demás nodos).
    1. Nota: el proceso tarda, según el tamaño del cluster de cassandra (ejecutar en un screen).
    2. Mucho ojo con el espacio en disco
  2. Si el removenode falla, ejecutar nodetool assassinate <IP Address> (desde cualquiera de los demás nodos).

Añadir un DataCenter

  • Con el “Cassandra” parado, “limpiar” posibles directorios de datos anteriores.

rm -rf /var/lib/cassandra/* <- OJO! No eliminar el directorio, únicamente el contenido.

  • Mientras se está “añadiendo” un nuevo Datacenter… es aconsejable que el cliente (los php’s del cliente), utilicen CONSISTENCY LOCAL_ONE, ó, LOCAL_QUORUM
  • Asegurarse que en Datacenter que está “UP”, está como NetworkTopologyStrategy… sinó es así, aplicar el siguiente “ALTER”:

ALTER KEYSPACE «sample_ks» WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘ExistingDC’ : 3 };

Revisar ficheros de configuración (añadir nombres, ips, etc… ):
/etc/cassandra/conf/cassandra.yaml

  • Añadir en el fichero “cassandra.yaml” una “seed” (la IP) en cada “Datacenter”. Ej. seeds: «217.13.124.41,94.24.114.104» ( 1 nodo del Datacenter1 y otro nodo del Datacenter 2)
  • Arrancar cada uno de los nuevos nodos del “nuevo Datacenter”
  • Añadir el nuevo Datacenter en los “keyspaces” del “antiguo Datacenter”. (hacerlo solo en 1 nodo).

ALTER KEYSPACE «sample_ks» WITH REPLICATION = {‘class’: ‘NetworkTopologyStrategy’, ‘ExistingDC’:3, ‘NewDC’:3};
Ej:
ALTER KEYSPACE system_distributed WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘dc1’ : 3, ‘dc2’ : 3 };
ALTER KEYSPACE system_traces WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘dc1’ : 3, ‘dc2’ : 3 };
ALTER KEYSPACE adtech WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘dc1’ : 3, ‘dc2’ : 3 };
ALTER KEYSPACE music WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘dc1’ : 3, ‘dc2’ : 3 };
Opcional (usuarios «globales»?):
ALTER KEYSPACE system_auth WITH REPLICATION = { ‘class’ : ‘NetworkTopologyStrategy’, ‘dc1’ : 3, ‘dc2’ : 3 };

  • Comprobar, desde consola del Cassandra que todo está OK:

SELECT * FROM system_schema.keyspaces;

  • Hacer “sincronización inicial” en CADA UNO de los NODOS NUEVOS:

nodetool rebuild — dc1

Añadir un Nodo

Tenemos varias variables a tener en cuenta a la hora de añadir un nodo a cassandra.

  • Auto_bootstrap. Variable que solo hace falta en el primer arranque de cassandra. Importante borrar esta opción después de la primera arrancada.
  • cluster_name. Nombre del cluster donde la vamos a añadir
  • listen_address / broadcast_address. IP de escucha / Ip de comunicación con otros nodos.
  • seed_provider. Sacar el nodo que queremos añadir de las semillas.

Importante: Estaría bien tener una copia de la configuración antes de levantar nada. Ya que allí vemos de forma rápida donde debemos cambiar la IP o la opción que necesitemos.

Importante: Mucho ojo con esta conf: cassandra-topology.properties

Squid3 Proxy Server

Squid3 Proxy Transparent Server
Squid3 Proxy Transparent Server

Servidor Proxy. Squid3

Servidor proxy o intermediario

Es un programa o dispositivo que lleva a cabo tareas de acceso a Internet en el lugar de otro ordenador. Es un punto intermedio entre un ordenador conectado a Internet y el servidor al cuál esta accediendo.

Hay miles de servidores proxy repartidos por el mundo, muchos de ellos gratuitos. Es importante tener en cuenta que este tipo de servidor intermedio lo podemos utilizar para ocultar nuestra propia dirección IP, deberíamos cruzar varios servidores introduciendo en cada server nuevo la dirección obtenida por el anterior. Cabe decir, que tu camino seguido en la red quedará registrado igualmente, aunque tu auténtica dirección ip estará tras los servidores  proxy o pasarela.

Servidor-proxy.png

Ventajas

  1. Las pasarelas permiten únicamente aquellos servicios para los cuales hay un servidor intermedio habilitado.
  2. El protocolo tambíen puede ser filtrado, por ejemplo, filtrando el protocolo  FTP, seria posible prohibir el uso de la orden «put».
  3. Podemos filtrar direcciones IP.
  4. El acceso a las páginas web es mucho más rápido.
  5. Los usuarios no tienen acceso al encaminador, comunicación bajo control.
  6. Filtración de web y palabras.
  7. Guarda informe de las conexiones
  8. Más protección delante de ataques externos.

Desventajas

  1. Hace falta configurar todas las aplicaciones para que tengan acceso a internet.
  2. Si el servidor proxy falla, la red se quedará sin internet.
  3. Requiere mantenimiento.

Hay miles de servidores proxy repartidos por el mundo, muchos de ellos gratuitos. Es importante tener en cuenta que este tipo de servidor intermedio lo podemos utilizar para ocultar nuestra propia dirección IP, deberíamos cruzar varios servidores introduciendo en cada server nuevo la dirección obtenida por el anterior. Cabe decir, que tu camino seguido en la red quedará registrado igualmente, aunque tu auténtica dirección ip estará tras los servidores  proxy o pasarela.

Squid para Linux

A Continuación el comando para la instalación y la ubicación del archivo de configuración de Squid en Debian o Ubuntu.

  • apt-get install squid
  • /etc/squid/squid.conf

Algunas de las configuraciones que encontraremos dentro del archivo squid.conf son:

http_port. Sirve para indicar el puerto donde trabaja este servidor, así como la dirección ip que tiene asignada.

  • http_port 3128
  • http_port 192.168.10.50:8080

cache_mem. Indicaremos la capacidad de memoria de nuestro caché en el servidor proxy. Hay que tener en cuenta que ponemos un 16MB para 128 MB de RAM.

  • cache_mem 16MB

cache_dir. El tamaño que le queremos dar una nuestra memoria proxy que, sera la encargada de almacenar nuestras páginas favoritas entre otras cosas.

  • cache_dir ufs /var/spool/squid 1024  1  256. Siendo 1024 al capacidad otorgada.

cache_mgr. Opción en la configuración para enviar un correo electrónico en caso de fallida.

  • cache_mgr 12345@gmail.com

cache_replacement-policy. Podemos utilizar direrentes algoritmos para gestionar la memoria proxy.

  • LRU Least Recently Used
  • LFUDA Least Frequently Used with Dynamic Aging
  • GDSF GreedyDual size Frequency

Una muestra de un archivo de configuración:

Servidor-squid.png Como podéis ver, primero se crean la reglas (acl). Podemos crear reglas tanto como para horarios, palabras, direcciones web, subredes… A continuación os comento algunas de ellas.

Para prohibir palabras,direcciones web o subredes deberemos crear un archivo alternativo al de configuración de Squid para cada objetivo, es decir, uno para palabras prohibidas o admitidas, otro para las subredes prohibidas o admitidas y otro para las direcciones web exactamente igual.

Para los horarios basta con conocer el código internacional de los días… M-Monday, T-Tuesday, W-Wednesday, H-Thursday, F-Friday, A-Saturday y S-Sunday.

El cache de nuestro servidor proxy se encuentra en /var/spool/squid3

Si instalamos calamaris, podemos generar informes listos para impresión de los diferentes accesos a nuestro proxy,

  • apt-get install calamaris
  • sudo cat /var/log/squid3/access.log | calamaris

Varnish – Apache2 – WordPress

wordpress logo
Varnish - Apache y WordPress
wordpress logo

Que es Varnish

Varnish es un acelerador HTTP, el cual almacena en caché los recursos de un servidor web y puede
crear la misma página una y otra vez cuando el usuario lo solicite. Se ejecuta frente a un servidor Web y
sirve las páginas mucho más rápido.

Funcionalidades

  • Equilibrio de Carga
  • Reescritura de URL
  • Comprobación de Backends
  • Manejo elegante de backend muertos
  • Soporte parcial para ESI(Edge Side Includes)

Arquitectura

  • Caché monolítica mapeada a memoria virtual
  • Archivos configuración compilados en C
  • Trata todo el ciclo de vida de una petición
  • Cambios de configuración en caliente
  • Logs escritos en memoria compartida

Herramientas

varnishtop ->Lista ocurrencias de los log mÃąs comunes
varnishstat ->Estadísticas en tiempo de real
varnishhist ->Hits y misses en tiempo real
varnishlog / varnishncsa ->Generan logs tradicionales
varnishreplay ->Parsea logs y reduce el trÃąfico
como validar la configuración -> varnishd -C -f /etc/varnish/default.vcl


Compilación de Varnish 4.1 en CentOs7

Para poder compilar sin problemas debemos tener instalados los siguientes paquetes:

pygpgme
yum-utils
epel-release-n
Para instalar epel-release-6 (Servidor de pruebas 6.9)


Vamos al directorio de repositorios y creamos el nuestro para Varnish

/etc/yum.repos.d/

Creamos el archivo varnishcache_varnish41.repo con el siguiente contenido:

[varnishcache_varnish41]

name=varnishcache_varnish41

baseurl=https://packagecloud.io/varnishcache/varnish41/el/6/$basearch

repo_gpgcheck=1

gpgcheck=0

enabled=1

gpgkey=https://packagecloud.io/varnishcache/varnish41/gpgkey

sslverify=1

sslcacert=/etc/pki/tls/certs/ca-bundle.crt

metadata_expire=300

[varnishcache_varnish41-source]

name=varnishcache_varnish41-source

baseurl=https://packagecloud.io/varnishcache/varnish41/el/6/SRPMS

repo_gpgcheck=1

gpgcheck=0

enabled=1

gpgkey=https://packagecloud.io/varnishcache/varnish41/gpgkey

sslverify=1

sslcacert=/etc/pki/tls/certs/ca-bundle.crt

metadata_expire=300


Procedemos a la instalación:

sudo yum -q makecache -y –disablerepo=’*’ –enablerepo=’varnishcache_varnish41′


Configuración Varnish

Parámetros de Arranque

Parámetros de arranque de Varnish, archivos de configuración:
/etc/sysconfig/varnish ->RedHat, CentOS, etc
/etc/default/varnish ->Debian, Ubuntu
# cat /etc/sysconfig/varnish
# Maximum number of open files (for ulimit -n)
NFILES=131072
# Locked shared memory (for ulimit -l)
# Default log size is 82MB + header
MEMLOCK=82000
# Maximum number of threads (for ulimit -u)
NPROCS=»unlimited»
# Maximum size of corefile (for ulimit -c). Default in Fedora is 0
# DAEMON_COREFILE_LIMIT=»unlimited»
# Init script support to reload/switch vcl without restart.
# To make this work, you need to set the following variables
# explicit: VARNISH_VCL_CONF, VARNISH_ADMIN_LISTEN_ADDRESS,
# VARNISH_ADMIN_LISTEN_PORT, VARNISH_SECRET_FILE.
RELOAD_VCL=1
# Set WARMUP_TIME to force a delay in reload-vcl between vcl.load and vcl.use
# This is useful when backend probe definitions need some time before declaring
# configured backends healthy, to avoid routing traffic to a non-healthy backend.
#WARMUP_TIME=0
# Main configuration file.
VARNISH_VCL_CONF=/etc/varnish/default.vc
# Default address and port to bind to
# Blank address means all IPv4 and IPv6 interfaces, otherwise specify
# a host name, an IPv4 dotted quad, or an IPv6 address in brackets.
VARNISH_LISTEN_PORT=80
# Telnet admin interface listen address and port
VARNISH_ADMIN_LISTEN_ADDRESS=127.0.0.1
VARNISH_ADMIN_LISTEN_PORT=6082
# Shared secret file for admin interface
VARNISH_SECRET_FILE=/etc/varnish/secret
# The minimum number of worker threads to start
VARNISH_MIN_THREADS=50
# The Maximum number of worker threads to start
VARNISH_MAX_THREADS=1000
# Cache file size: in bytes, optionally using k / M / G / T suffix.
VARNISH_STORAGE_SIZE=256M
# Backend storage specification
VARNISH_STORAGE=»malloc,${VARNISH_STORAGE_SIZE}»
# Default TTL used when the backend does not specify one
VARNISH_TTL=120
# DAEMON_OPTS is used by the init script.
DAEMON_OPTS=»-a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} \
-f ${VARNISH_VCL_CONF} \
-T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} \
-p thread_pool_min=${VARNISH_MIN_THREADS} \
-p thread_pool_max=${VARNISH_MAX_THREADS} \
-S ${VARNISH_SECRET_FILE} \
-s ${VARNISH_STORAGE}»
Las opciones más importantes son VARNISH_PORT Y VARNISH_VLC_CONF, sin estas dos parámetros no funcionará.
 

Funciones Varnish – Rutinas

Cuando una petición HTTP llega a Varnish, éste la procesa llamando a las diferentes rutinas en un orden concreto, y se ejecuta el código que hay dentro de dichas subrutinas. Ese código puede ser el código por defecto de Varnish o bien código personalizado por nosotros.

De estas rutinas las que más vamos a usar son: vcl_recv() y vcl_fetch(), aunque vamos a ver todas las opciones disponibles:*

  • vcl_recv() >Cuando se recibe una petición HTTP Varnish lanza esta subrutina. Nos permite decidir si la aceptamos o no, cómo hacerlo y que backend usar.
  • vcl_fecth() >Se ejecuta después de haber obtenido del backend HTTP los datos solicitados, después de haberse acepta la petición de vcl_recv().

En todas las funciones podemos realizar diferentes acciones, para ello tenemos la función return() con las diferentes acciones dentro de ella:

  • pass ->Si para la petición en curso devolvemos pass, la peticiÃşn se envia al servidor Backend sin buscarse en la caché y la respuesta del backend http se devuelve al usuario sin cachearse.
  • pipe ->Esta acciÃşn çortocircuita. el cliente HTTP y el Backend HTTP de forma que Varnish se limita a transferir datos de uno a otro. Es similar a pass (no se cachea) y ademÃąs Varnish no se dedica a inspeccionar el trÃąfico HTTP ni rellenar los objetos req/beresp/obj por lo que a veces se utiliza para evitar que objetos muy grandes (vÃŋdeos, etc) sean «procesados»por varnish.
  • lookup ->Fuerza a Varnish a que devuelva el objeto desde la caché incluso si la petición en sí mísma está solicitando contenido no cacheado.
  • deliver ->Le indica a Varnish que queremos devolver el objeto cacheado si es posible.
  • hit_for_pass ->Similar a pass (pero accesible desde vcl_fetch) salvo porque crea un objeto de tipo hitforpass y lo que se hace en este caso es cachear la decisión de no cachear.
  • restart ->Una forma de volver a ejecutar la lógica desde el principio.
  • vcl_hash() >Permite alterar el hash que se utiliza para gestionar el objeto en la cachÃľ. Normalmente es la URL pero podemos alterar dicho hash a nuestra voluntad. Un ejemplo sería cachear la página del perfil (/profile/) de cada usuario, aÃśadiendo concatenando la cookie de usuario a la URL, lo que generaría un objeto distinto en cada para cada usuario.
  • vcl_pipe() >Modo Pipe
  • vcl_pass() >Podemos forzar a que se reinicie la transacción, lo cual incrementa un contador interno de restart»que podemos detectar en otras funciones.
  • vcl_hit() >Llamada cuando lookup en la caché encuentra un objeto válido.
  • vcl_miss() >Es llamada cuando lookup no encuentra un objeto válido.
  • vcl_error() >LLamada cuando se encuentra un error por cualquier motivo.
  • vcl_deliver() >Es llamada antes de que un objeto cacheado sea entregado al cliente HTTP.

Configuración Caché

Tenemos el fichero /etc/varnish/default.vlc

Archivo de ejemplo:
# This is a basic VCL configuration file for varnish. See the vcl(7)
# man page for details on VCL syntax and semantics.
#
# Default backend definition. Set this to point to your content
# server.
#
backend default {
.host = «127.0.0.1»;
.port = «8080»;
sub vcl_recv {
# Happens before we check if we have this in cache already.
# Typically you clean up the request here, removing cookies you don’t need,
# rewriting the request, etc.
#Capamos las cookies de wordpress para wp-login y wp-admin
if (!(req.url ~ «wp-(login|admin)»)) {
unset req.http.cookie;
}
#Capamos para el de cookies que podrían afectar al administrador
set req.http.cookie = regsuball(req.http.cookie, «wp-settings-\d+=[^;]+(; )?», «»);
set req.http.cookie = regsuball(req.http.cookie, «wp-settings-time-\d+=[^;]+(; )?», «»);
set req.http.cookie = regsuball(req.http.cookie, «wordpress_test_cookie=[^;]+(; )?», «»);
if (req.http.cookie == «») {
unset req.http.cookie;
}
#No se cachea todo lo que acabe con wp-admin o wp-login
if (req.url ~ «wp-admin|wp-login») {
return (pass);
}
}
sub vcl_backend_response {
# Happens after we have read the response headers from the backend.
# Here you clean the response headers, removing silly Set-Cookie headers
# and other mistakes your backend does.
}
sub vcl_deliver {
# Happens when we have all the pieces we need, and are about to send the
# response to the client.
# You can do accounting or modifying the final object here.
}
 
El lenguaje de configuración de Varnish llamado VCL(Varnish Configuration Language). En esta configuración debemos definir una serie de subrutinas y código dentro de las mismas. Varnish llamará a cada una de esta subrutinas en algún punto de la petición.
Este lenguaje soporta estructuras «tipo if, include, comentarios de como //, /* */ y , salida de funciones con return(), asignaciones con =, comparaciones con ==, negaciÃşn con !, and y or lógico con y ||, matche o contra expresiones regulares con y establecer/eliminar atributos con set y unset. También tenemos funciones como regsub y regsuball (sustituciÃşn por expresiones regulares de una o todas las ocurrencias).
 

Varnish y WordPress

Varnish y el contenido dinámico de WordPress (prácticamente todo) no se llevan muy bien, para ello debemos configurar varnish para que ciertos contenidos los muestre estáticamente.
Ejemplo default.vcl para WordPress

vcl 4.0;

import std;

# Default backend definition. Set this to point to your content server.

backend default {

.host = «127.0.0.1»;

.port = «8080»;

}

#Backend net-lz.com

backend netlz {

.host = «127.0.0.1»;

.port = «8080»;

}

#Backend gamesranking.info

backend gamesranking {

.host = «127.0.0.1»;

.port = «8080»;

}

#Backend trailersdecine.com

backend trailersdecine {

.host = «127.0.0.1»;

.port = «8080»;

}

sub vcl_recv {

#Control para ver que backend utilizar

if (req.http.host == «www.net-lz.com» || req.http.host == «net-lz.com»){

set req.backend_hint = netlz;

} elseif (req.http.host == «www.gamesranking.net» || req.http.host == «gamesranking.net»){

set req.backend_hint = gamesranking;

} elseif (req.http.host == «www.trailersdecine.com» || req.http.host == «trailersdecine.com»){

set req.backend_hint = trailersdecine;

}else {

set req.backend_hint = default;

}

#Si la petición es para 443 nos aseguramos que lo marqué en las cabeceras HTML
if (std.port(server.ip) == 443){
set req.http.X-Proto = «https»;

}

#Tipos de codificaciones aceptadas

if (req.http.Accept-Encoding) {

if (req.url ~ «\.(gif|jpg|jpeg|swf|flv|mp3|mp4|pdf|ico|png|gz|tgz|bz2)(\?.*|)$») {
# remove req.http.Accept-Encoding;
} elsif (req.http.Accept-Encoding ~ «gzip») {

set req.http.Accept-Encoding = «gzip»;

} elsif (req.http.Accept-Encoding ~ "deflate") {

set req.http.Accept-Encoding = «deflate»;

} else {

#remove req.http.Accept-Encoding;

}

}

#Consultas archivos multimedia

if (req.url ~ «wp-content/themes/» && req.url ~ «\.(gif|jpg|jpeg|swf|css|js|flv|mp3|mp4|pdf|ico|png)(\?.*|)$») {

unset req.http.cookie;

set req.url = regsub(req.url, "\?.*$", "");

}

#Consultas a otro tipos de archivos

if (req.url ~ «\?(utm_(campaign|medium|source|term)|adParams|client|cx|eid|fbid|feed|ref(id|src)?|v(er|iew))=») {

set req.url = regsub(req.url, "\?.*$", "");

}

# no cacheamos las cookies de administrador

# soluciona la redirección que se generaba al querer entrar como administrador

if (req.http.cookie) {

if (req.http.cookie ~ «(wordpress_|wp-settings-)») {

return(pass);

} else {

unset req.http.cookie;

}

}

#Desactivamos la cache para esta url

if (!(req.url ~ «wp-(login|admin)»)) {

unset req.http.cookie;

}

#No cacheamos cookies específicas de wordpress

set req.http.cookie = regsuball(req.http.cookie, «wp-settings-\d+=[^;]+(; )?», «»);

set req.http.cookie = regsuball(req.http.cookie, «wp-settings-time-\d+=[^;]+(; )?», «»);

set req.http.cookie = regsuball(req.http.cookie, «wordpress_test_cookie=[^;]+(; )?», «»);

#No cacheamos cookies en general

if (req.http.cookie == «») {

unset req.http.cookie;

}

#Pasamos sin cacheo las url con wp-admin y wp-login

if (req.url ~ «wp-admin|wp-login») {

return (pass);

}

}

#fin vcl_recv


sub vcl_backend_response {

set beresp.ttl = 10s;

set beresp.grace = 1h;

}

#Marcamos que debemos guardar cómo estadísticas

sub vcl_deliver {

if (obj.hits > 0) {

set resp.http.X-Cache = «HIT»;

} else {

set resp.http.X-Cache = «MISS»;

}

return (deliver);

}

Podríamos añadir una configuración para permitir la opción purge desde diferentes sitios, este no se ha hecho debido a que tenemos instalado un plugin en la red multisite de worpdress que nos ofrece esta funcionalidad y la configuración Varnish ha sido diseñada con esta objetivo. Ver: https://varnish-cache.org/trac/wiki/VCLExamples


Configuración Varnish especiales

REMOTE ADDRESS PHP

Para que PHP pueda capturar las Ip de los usuarios que se conectan debemos añadir algunos cambios al archivo default.vcl de varnish.


Añadimos la siguiente configuración dentro del la subrutina vcl_recv:


#Control Varnish para que PHP puede devolver las IP de los usuarios que se conectan

if (req.restarts == 0) {

if (req.http.x-forwarded-for) {


set req.http.X-Forwarded-For =

req.http.X-Forwarded-For + «, » + client.ip;


} else {

set req.http.X-Forwarded-For = client.ip;

}

}


Ahora nos faltará 2 procesos, añadir unas líneas al Vhost de correspondiente y crear un fichero php que se encargará de asegurarnos que cojamos la ip buena.


Vhost de ejemplo:

<VirtualHost *:8080>

DocumentRoot «/web/wordpress/static/trailersdecine»

ServerName trailersdecine.com

ServerAlias www.trailersdecine.com

<Directory /web/wordpress/static/trailersdecine>

#Linea para Varnish

php_value auto_prepend_file «/www/conf/sites/varnish_client_ip.php»

AllowOverride All

Order deny,allow

Allow from all

</Directory>


CustomLog logs/common.trailersdecine combined

ErrorLog logs/error.trailersdecine

#Linea y log para varnish

LogFormat «%{X-Forwarded-For}i %l %u %t \»%r\» %>s %b \»%{Referer}i\» \»%{User-Agent}i\»» varnish


# Other directives here

</VirtualHost>


Como podéis observar dentro de Directory podemos ver como se hace una llamada al archivo varnish_client_ip.php, vamos a crearlo con el siguiente cotenido:


<?phpif( isset( $_SERVER[ ‘HTTP_X_FORWARDED_FOR’ ] ) ) {

$_SERVER[ 'REMOTE_ADDR' ] = $_SERVER[ 'HTTP_X_FORWARDED_FOR' ];

}

?>


Con tal de no parar el servicio vamos a recargar ambos

service varnish reload

/www/bin/apachectl stop

/www/bin/apachectl start


Ya tenemos nuestro servicio ce cacheo listo


MOD HEADERS

Con tal de controlar las cabeceras que viene de http y https y permitir el trasposo de archivos multimedia entre estos dos protocolos debemos añadir configuración tanto a Varnish como en Apache.


Varnish mod_headers.

sub vcl_recv {
# Save Origin in a custom header
set req.http.X-Saved-Origin = req.http.Origin;
# Remove Origin from the request so that backend
# doesn’t add CORS headers.
unset req.http.Origin;
…
}
sub vcl_deliver {
if (req.http.X-Saved-Origin == «https://www.trailersdecine.com«
|| req.http.X-Saved-Origin == «http://www.trailersdecine.com«
|| req.http.X-Saved-Origin == «https://trailersdecine.com«
|| req.http.X-Saved-Origin == «http://trailersdecine.com«) {
set resp.http.Access-Control-Allow-Origin =
req.http.X-Saved-Origin;
}
if (resp.http.Vary) {
set resp.http.Vary = resp.http.Vary + «,Origin»;
} else {
set resp.http.Vary = «Origin»;
}
…
}
Apache mod_headers.
Para compilar el módulo si este no esta instalado:
/www/bin/apxs -i -c ./modules/metadata/mod_headers.c
Activación del módulo en Apache
En httpd.conf añadir al final
LoadModule headers_module /www/modules/mod_headers.so
En los Vhost de los dominios a controlar las cabeceras añadimos las línea:
Header set Access-Control-Allow-Origin «*»
Reiniciamos apache y Varnish y ya esta listo
 
 
 
 

Configuración Apache para Varnish

Como Varnish está a la escucha en el puerto 80, debemos indicarle a Apache que escuche en otro puerto, en este caso el 8080.

#Puertos de escucha

Listen *:8080

Listen *:443

#Módulos necesarios

LoadModule proxy_modulemodules/mod_proxy.so

LoadModule proxy_balancer_modulemodules/mod_proxy_balancer.so

LoadModule proxy_http_modulemodules/mod_proxy_http.so

LoadModulos mod_ssl

#NameVirtualHost

Este paso no es estrictamente necesario

NameVirtualHost *:8080NameVirtualHost 217.13.124.73:443


Virtualhost para sitios sin SSL

<VirtualHost *:8080> DocumentRoot «/web/wordpress/static/trailersdecine» ServerName trailersdecine.com ServerAlias www.trailersdecine.com <Directory /web/wordpress/static/trailersdecine> AllowOverride All Order deny,allow Allow from all </Directory> CustomLog logs/common.trailersdecine combined ErrorLog logs/error.trailersdecine # Other directives here</VirtualHost>

Es una configuración típica excepto con los puertos de escucha y con el puerto de escucha a la hora de configurar el Vhost: 8080.


Varnish y HTTPS

Archivo:Image1.png.png


Varnish no soporta HTTPS, no podemos configurar Varnish para que escuche el puerto 443 simplemente.


Para solucionar este problema debemos configurar el virtualhost de la siguiente manera:

Virtualhost 443
<VirtualHost 217.13.124.73:443>
ServerName trailersdecine.com
ServerAlias www.trailersdecine.com
ErrorLog logs/error_https.trailersdecine.com.log
CustomLog logs/access_https.trailersdecine.com.log combined
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile «/etc/letsencrypt/live/trailersdecine.com/fullchain.pem»
SSLCertificateKeyFile «/etc/letsencrypt/live/trailersdecine.com/privkey.pem»
ProxyPreserveHost On
ProxypassReverse/ http://127.0.0.1:8080/
</VirtualHost>
Podemos apreciar varias cosas en este fichero:
No tiene la sentencia DocumentRoot
Creamos la contestación a partir de la dirección interna y el puerto del escucha de Apache2
Una vez creado el VirtualHost para el puerto 443, reiniciamos los servicios y ya tenemos Varnish – Apache – HTTPS funcionando.
En la configuración de apache deberemos añadir:
NameVirtualHost 217.13.124.73:443

Enlaces de referencia

https://bash-prompt.net/guides/apache-varnish/

Let’s encrypt

Comandos

Let’s encrypt

En RomSolutions la seguridad informática es muy importante, tanto o más que el posicionamiento SEO. Para tener un buen posicionamiento SEO debemos tener nuestra web bajo el protocolo HTTPS, sin este protocolo google no nos posicionará en sus listas.

Para obtener un certificado SSL tenemos varias opciones:

  • Como para la forma de obtenerlo,
  • El tipo de certificado que queremos obtener
  • Los dominios que abarcará este certificado.

Tenemos tres modos de ejecucción por defecto:

  • por defecto. letsencrypt-auto …. Este modo obtiene el certificado y lo instalo en el vhost correspondiente.
  • certonly. letsencrypt-auto certonly. Este modo solo obtiene el certificado
  • renew. Este método solo renueva el certificado

Certificado para uno o más dominios

letsencrypt-auto certonly -d dominio1.com -d pepe.dominio1.com -d dominio2.como

Certificado según la vía

letsencrypt-auto certonly –preferred-challenges dns -d dominio1.com
letsencrypt-auto certonly –preferred-challenges http -d dominio1.com
letsencrypt-auto certonly –preferred-challenges tls-sni -d dominio1.com (https)

Certificado via fichero de texto

letsencrypt-auto certonly –manual -d dominio1.com

Certificado indicando webroot

letsencrypt-auto certonly –webroot -w /tmp -d www.pepe.com -d pepe.com

WildCard

letsencrypt-auto certonly –server https://acme-v02.api.letsencrypt.org/directory –manual -d «*.dominio.com»

Nota: Para obtener el wildcard necesitaremos acceso al servidor de nombres DNS.

Renovación simple

letsencrypt-auto renew

Renovación apagando servicios

letsencrypt-auto renew –renew-hook=»/etc/rc.d/init.d/nginx restart»

Revocar un certificado

letsencrypt-auto revoke –cert-path /etc/letsencrypt/archive/${YOUR_DOMAIN}/cert1.pem

Comprobar certificado sin letsencrypt

openssl x509 -in <certificat> -noout -dates

Averiguar Dominios de un certificado

openssl x509 fichero -nouout -text

Let’s encrypt es una de las mejores opciones a la hora de obtener un certificado.

Bosques aleatorios para regresión

Regresión con bosques aleatorios

Bosques aleatorios

Versión mejorada del árbol de regresión ya que es capaz de utilizar miles de árboles de regresión para obtener una mejor predicción.

Pasos a seguir

  1. Elegir un número aleatorio K de puntos de datos del conjunto de Entranamiento.
  2. Árbol de desición asociado a esos K puntos.
  3. Elegir el número de NTree de árboles que queremos construir y repetimos Paso 1 y Paso 2
  4. Cada uno de los árboles hace una predicción del valor Y, luego hacemos un promedio de esos NTree predicciones.

Árboles de decisión para Regresión Lineal

CART -> Classification and Regressión Tree

Una vez ejecutamos nuestro algoritmo árbol de decisión, el conjunto de datos de las variables independientes quedará dividido en segmentos.

Arbol de decision.png

Básicamente se fija en la entropia de los puntos para poder agruparlos, cada una de estas divisiones aporta una información realmente buena.

Arbol decision2.png

Podemos ver en verda la media de los segmentos y en la imagen de abajo el árbol de decisiones

Arbol decision3.png

 
 

Regresión con máquina de soporte vectorial

Regresión con máquina de soporte vectorial SVR

Sirven tanto para regresiones lineales como no lineales. La idea es ajustar una calle, he intentar mantener cuántas más obvervaciones posibles del conjunto de datos dentro de la calle, limitando unos márgenes máximos.

Hyper parámetro épsilon

La anchura del pasillo se controla mediante un hiper parámetro, épsilon. Cuánto mayor es ese valor, mayor es la anchura de la calle.

Objetivo

En la regresión lineal se intenta minimizar el error entre la predicción y los datos. En SVR el objetivo es que los errores no superen el umbral establecido.