Como ya vimos en un artículo anterior, los replica sets nos ofrecen alta disponibilidad para nuestros despliegues de mongodb. Sin embargo, algunas veces, necesitamos que nuestro cluster ofrezca alto rendimiento, y esto se consigue mediante sharding. Como no queremos renunciar a la alta disponibilidad, podemos aplicar ambas; hoy explicamos como.
Harto de distribuciones para escritorio cargados con aplicaciones que no se usan, decidí que esta vez iba a instalar un escritorio de trabajo partiendo de una Debian netinstall. El resto va a ser instalar las aplicaciones justas y necesarias para nuestro trabajo diario. En este artículo describo como lo hice.
El otro día estuve optimizando unos scripts hechos en bash que había hecho otro. Como resultado del lenguaje usado era un caos de comandos, muchos de ellos para limpiar la salida y darle la forma adecuada. Los reescribí en python usando la librería cx_Oracle, que compilé en un fichero wheel.
Cuando nos encontramos delante de servidores únicos, es bastante fácil su gestión. Sin embargo, cuando tenemos 8 instancias de cada tipo de servidor, las tareas se vuelven lentas y repetitivas. Podemos incluso automatizar la gestión de una sola máquina para hacer su entorno fácilmente reproducible, en vistas a su reconstrucción.
Siempre que estoy trabajando en un servidor CentOS o RedHat, veo que las versiones de python que usan son bastante viejas. De hecho, hay una gran mejora de python entre las versiones 2.4, 2.6 y 2.7; así que es frecuente compilar una versión superior para nuestro uso.
Trabajando con contenedores tenemos una parte que se repite: el sistema de ficheros base, que copiamos siempre. Otras veces nos puede interesar hacer un sistema capaz de descartar los cambios desde un punto inicial. Podemos crear una capa base de solo lectura y añadir otra capa de cambios con aufs.
Acabamos el artículo anterior de esta serie con las aplicaciones corriendo en sus respectivas máquinas. En este artículo vamos a poner una fachada a todo el sistema, mediante un proxy HTTP que haga las funciones de terminación SSL y de balanceador, exponiendo todo el sistema en una sola dirección IP.
En el artículo anterior de esta serie montamos el cluster de la base de datos que íbamos a necesitar para las aplicaciones que conformaban este entorno de ejemplo. Ahora que tenemos la base de datos, falta poner los servidores de aplicaciones que sirven nuestras aplicaciones y que usan el cluster.
Seguimos con la serie de montar un entorno escalable. Tras explicar en el primer artículo lo que vamos a montar, seguimos con ello. En este artículo vamos a montar un cluster de bases de datos; será mongodb porque la aplicación lo requiere y usará la topología de un replica set.
Mucha gente tiene un servidor único para alojar páginas web dinámicas, por ejemplo con PHP y con MySQL. Sin embargo, a veces esto puede resultar insuficiente; nos puede interesar tener un entorno de bajas especificaciones y de bajo coste, pero preparado crecer al mismo ritmo que lo hacen los usuarios.
«« « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 » »»