Un resumen con los pros y contras que conlleva cada modelo de clasificación
Seguir leyendoResumen Postgresql

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.
- 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.
- 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.
- ./psql base_datos < archivo_creador_tablas_y_campos.sql
- Ahora haremos los mismo con los datos, No con el archivo de restricciones resultante de la edición del paso 1!!.
- ./psql base_datos < archivo_con_datos.sql
- 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.
- ./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

Importar de Json a MongoDB
sudo ./mongoimport –db actitvitat1 –collection people < ../data/db/persons.json
Crear sentencias Mongo
- Ens connectem al servidor mongo a la base de dades activitat1sudo ./mongo localhost/activitat1
- Mostrem tot el contingut de la col·lecció peopledb.people.find()
- Mostrem tot el contingut de la col·lecció people d’una manera més llegible.db.people.find().toArray()
- Mostrem les persones de 34 anys d’una manera llegibledb.people.find({age:34}).toArray()
- Mostrem les persones de 34 anys i que siguin actius.db.people.find({age:34,isActive:true}).toArray()
- 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()
- 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()
- Mostra una persona que compleixi els requeriments anteriors.
db.people.find({age:34,isActive:true},{name:1,age:1,_id:0}).limit(1) - Mostrem el nom i la edat de les persones que tenen més de 30 anysdb.people.find({age:{$gte:30}}).toArray()
- Mostrem el nom i la edat de les persones que tenen 30 o més anysdb.people.find({age:{$gte:30}},{name:1,age:1,_id:0}).toArray()
- Mostrem el nom i la edat de les persones menors de 30 anysdb.people.find({age:{$lt:30}},{name:1,age:1,_id:0}).toArray()
- Mostrem el nom i la edat de les persones que no tenen 30 anysdb.people.find({age:{$ne:30}},{name:1,age:1,_id:0}).toArray()
- 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() - 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()
- Busquem els documents el camp gender sigui «female» o el camp age sigui més gran que 20db.people.find({$or:[{age:{$gte:30}},{gender:»female»}]},{name:1,age:1,_id:0}).toArray()
- 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()
- 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()
- 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}]}) - 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}]}) - Volem trobar totes les persones que continguin en tags els valors laborum i sunt.
db.people.find({$and:[{tags:»laborum»},{tags:»sunt»}]}).toArray() - Volem trobar totes les persones que continguin en tags alguns dels valors laborum, sunt, nisi
db.people.find({tags:{$all:[«laborum»,»sunt»,»nisi»]}}).toArray() - Volem trobar totes les persones que NO continguin a l’array tags alguns dels valors especificats: laborum, sunt i, nisi
- Retornar tots els documents on l’array tags té una mida de 3 elements
- 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
- db.people.find({«friends.2.name»:{$gte:»T»}}).count()Cuenta las per
- db.people.find({«friends.2.name»:{$gte:»T»}},{_id:0,name:1}).sort({name:1})
- db.people.find({«friends.2.name»:{$gte:»T»}},{_id:0,name:1}).sort({name: -1})
- db.people.find({«friends.2.name»:{$gte:»T»}},{_id:0,name:1,email:1}).sort({name:1,email:1})
- db.people.find({«friends.2.name»:{$gte:»T»}},{name:1}).limit(5)
- db.people.find({«friends.2.name»:{$gte:»T»}},{name:1}).skip(5)
- var myArray = db.people.find({«friends.2.name»:{$gte:»T»}},{name:1}).toArray()
- db.people.find({«friends.2.name»:{$gte:»T»}},{name:1}).skip(10).limit(5)
- 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

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:
- Escritura de la operación de inserción de datos en el commit log.
- Escritura de los datos en memtable
- Flushing de los datos desde memtable.
- 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.
- Asegurate que el SysFs rotational flag está en false.
- Aplicamos la misma marca de rotación para cualquier dispositivo de bloque creado desde el almacenamiento SSD, como mdarrays.
- Establecer el scheduler IO en fecha límite o noop.
- 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.
- 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.
- 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:
- Para importar datos de un nodo debemos apagar el nodo donde queremos importar los datos
systemctl stop cassandra
- Una vez apagado, debemos eliminar los datos anteriores:
Eliminar datos de:
/var/lib/cassandra/data/adtech/geosc-numeroID/*.db
- Copiamos el interior del snapshot dentro de:
/var/lib/cassandra/data/adtech/geosc-numeroID/
- Encendemos cassandra y refrescamos la tabla.
systemctl start cassandra
nodetool refresh adtech.geosc
- 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
- Asegurarse de que el nodo esta UP/DOWN usando nodetool status (UN=up, DN=down):
- 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)
- Si el nodo está DOWN, ejecutar nodetool removenode <Host ID> (desde cualquiera de los demás nodos).
- Nota: el proceso tarda, según el tamaño del cluster de cassandra (ejecutar en un screen).
- Mucho ojo con el espacio en disco
- 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:
- Escritura de la operación de inserción de datos en el commit log.
- Escritura de los datos en memtable
- Flushing de los datos desde memtable.
- 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.
- Asegurate que el SysFs rotational flag está en false.
- Aplicamos la misma marca de rotación para cualquier dispositivo de bloque creado desde el almacenamiento SSD, como mdarrays.
- Establecer el scheduler IO en fecha límite o noop.
- 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.
- 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.
- 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:
- Para importar datos de un nodo debemos apagar el nodo donde queremos importar los datos
systemctl stop cassandra
- Una vez apagado, debemos eliminar los datos anteriores:
Eliminar datos de:
/var/lib/cassandra/data/adtech/geosc-numeroID/*.db
- Copiamos el interior del snapshot dentro de:
/var/lib/cassandra/data/adtech/geosc-numeroID/
- Encendemos cassandra y refrescamos la tabla.
systemctl start cassandra
nodetool refresh adtech.geosc
- 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
- Asegurarse de que el nodo esta UP/DOWN usando nodetool status (UN=up, DN=down):
- 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)
- Si el nodo está DOWN, ejecutar nodetool removenode <Host ID> (desde cualquiera de los demás nodos).
- Nota: el proceso tarda, según el tamaño del cluster de cassandra (ejecutar en un screen).
- Mucho ojo con el espacio en disco
- 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

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.
Ventajas
- Las pasarelas permiten únicamente aquellos servicios para los cuales hay un servidor intermedio habilitado.
- El protocolo tambíen puede ser filtrado, por ejemplo, filtrando el protocolo FTP, seria posible prohibir el uso de la orden «put».
- Podemos filtrar direcciones IP.
- El acceso a las páginas web es mucho más rápido.
- Los usuarios no tienen acceso al encaminador, comunicación bajo control.
- Filtración de web y palabras.
- Guarda informe de las conexiones
- Más protección delante de ataques externos.
Desventajas
- Hace falta configurar todas las aplicaciones para que tengan acceso a internet.
- Si el servidor proxy falla, la red se quedará sin internet.
- 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:
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


Que es Varnish
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
Compilación de Varnish 4.1 en CentOs7
Para poder compilar sin problemas debemos tener instalados los siguientes paquetes:
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
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
Varnish y 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»){
} elseif (req.http.host == «www.gamesranking.net» || req.http.host == «gamesranking.net»){
} elseif (req.http.host == «www.trailersdecine.com» || req.http.host == «trailersdecine.com»){
}else {
}
#Si la petición es para 443 nos aseguramos que lo marqué en las cabeceras HTML
}
#Tipos de codificaciones aceptadas
if (req.http.Accept-Encoding) {
# remove req.http.Accept-Encoding;
set req.http.Accept-Encoding = «gzip»;
} elsif (req.http.Accept-Encoding ~ "deflate") {
set req.http.Accept-Encoding = «deflate»;
#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.
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
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:
Enlaces de referencia
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
- Elegir un número aleatorio K de puntos de datos del conjunto de Entranamiento.
- Árbol de desición asociado a esos K puntos.
- Elegir el número de NTree de árboles que queremos construir y repetimos Paso 1 y Paso 2
- 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.
Básicamente se fija en la entropia de los puntos para poder agruparlos, cada una de estas divisiones aporta una información realmente buena.
Podemos ver en verda la media de los segmentos y en la imagen de abajo el árbol de decisiones
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.