Estoy en AWS con mis clientes desde hace mucho tiempo, pero ahora necesitaré reducir costos para seguir brindando mis servicios. En AWS estoy usando RSync para mantener algunas carpetas sincronizadas y DRDB para proporcionar alta disponibilidad con conmutación por error transparente teniendo siempre un espejo operativo y listo para usar para cada máquina cliente.
Ahora no puedo seguir usando DRBD porque la solución en la nube mucho más barata que estoy migrando solo proporciona para cada máquina un Ubuntu 14.04 LTS con solo una partición y sin LVM, esta plataforma en la nube también se ha convertido en un requisito para algunos de mis clientes.
La solución en la que estoy pensando es programar scripts de shell para BKP diario en un lado, transferirlos por SSH a otro lado y restaurar el BKP; se volverá complejo, propenso a errores y necesitará mucho trabajo para desarrollarlo y administrarlo. .
Muchos de mis clientes son solo Wordpress+Mysql y aceptan un día de retraso, estoy buscando alternativas para brindar "alta disponibilidad" aunque venga con un día de retraso que no me obligue a desarrollar y administrar scripts para cada uno. caso con el contexto restringido.
Respuesta1
Si realmente no puede utilizar de manera viable un dispositivo de bloque (DRBD probablemente sería mejor aquí y ya tiene experiencia con él), GlusterFS puede brindarle las funciones de replicación que busca a nivel de archivo.
Los "ladrillos" de Gluster, aunque idealmente son un dispositivo de almacenamiento singular con su propia pila LVM delgada que termina en XFS, en realidad pueden ser cualquier sistema de archivos compatible con POSIX (o incluso simplemente un directorio en lugar de un FS dedicado) en un nodo.
Estos ladrillos se agregan en un "volumen" unificado con una política de "réplica" que define ahora muchos ladrillos que se escribirán con cualquier archivo determinado; en este caso, probablemente la réplica 2 o 3. Estas réplicas se esforzarán por ubicarse en diferentes nodos si en todo posible.
La semántica de fallas con Gluster aún no es tan coherente como con DRBD. Las condiciones de cerebro dividido son más fáciles de lograr ya que la replicación de datos es responsabilidad del cliente que se conecta (envía N copias de todas las escrituras a cada nodo de Gluster en lugar de escribir a un maestro que luego replica los datos). Sin embargo, puede ser potencialmente más fácil resolver cerebros divididos con datos divergentes, ya que cada bloque es un sistema de archivos intacto con datos completamente legibles cuando se utiliza la replicación.
No será tan rápido como DRBD, pero ¿quizás no necesites que lo sea?