Re: Consejo - Alta disponibilidad en amazón
2013/8/21 C. L. Martinez <carlopmart@gmail.com>:
> 2013/8/21 Camaleón <noelamac@gmail.com>:
>> El Wed, 21 Aug 2013 09:42:20 +0200, Maykel Franco escribió:
>>
>>> El día 20 de agosto de 2013 17:21, Camaleón <noelamac@gmail.com>
>>> escribió:
>>
>> (...)
>>
>>>>> Justo ahí, me gustaría que el dns example.com que apuntaba a la ip
>>>>> fija de mi empresa, ahora cambie debido a la falla y apunte a la ip
>>>>> fija pública de amazon donde teneoms otra VM...
>>>>>
>>>>> Si me explicado mal, me lo decís.
>>>>
>>>> (...)
>>>>
>>>> Si, si es lo mismo que lo que te comento de la técnica del RR
>>>> (básicamente se trata de tener varios registros "A" estáticos que son
>>>> consultados de manera consecutiva cuando el primero que responde no
>>>> está accesible), sólo que tú estás pensando en un sistema de
>>>> implementación distinto (actualizar las entradas de la zona de tu
>>>> dominio para que apunten a otro servidor cuando no responda, para cual
>>>> necesitarás una configuración en clúster o HA de los equipos o tener
>>>> algún sistema de detección que le indique al DNS que se actualice).
>>
>>> Lo he entendido bien pero tengo alguna duda y es que por ejemplo si en
>>> vez de fallar la linea que tengo contratada fallan mis 2 apaches que
>>> tenemos en la red local...Cómo se da cuenta nuestro dns en este caso
>>> nominalia de que mi servidor web apache se ha caído para cambiar el dns
>>> example.com y resolverlo a amazon??
>>
>> Supongo que te refieres cuando usas el sistema de DDNS.... Pues se daría
>> cuenta porque el host no estaría respondiendo.
>>
>> No sé qué tipo de sistema de monitorización usarán los servicios
>> configurados en HA o los clústers, quizá un simple ping al servidor web
>> cada "x" tiempo y si hay pérdida de paquetes actualizan los registros DNS
>> de la zona para asignar la carga a otro registro.
>>
>>> Si yo pongo 2 registros en nominalia, por ejempo:
>>>
>>> TIPO A: example.com --> 6.5.3.5 --> mi ip estatica publica de mi ISP
>>> TIPO A: example.com --> 8.3.4.2 --> AMAZON
>>
>> Con el sistema round-bind no tienes que hacer nada, tan sólo asignarle
>> prioridad al registro principal (servidor alojado por ti) para que cuando
>> no responda a las peticiones salte automáticamente a los siguientes
>> registros.
>>
>> Por aquí lo explican mejor, con ejemplos de uso:
>>
>> DNS round robin for web server failover
>> http://www.nber.org/sys-admin/dns-failover.html
>>
>> HOWTO - Configure Load Balancing
>> http://www.zytrax.com/books/dns/ch9/rr.html
>>
>> Este sistema no es infalible y el cliente puede notar un pequeño retardo
>> en cargar la página en el caso de que el servidor primario esté fuera de
>> combate, pero bueno, ya te dije que era el "balanceo de los pobres" :-P
>>
>>> Y otra cosa, a que te refieres con GeoLocalización y para que me puede
>>> servir en este caso??
>>
>> ¿Ein?
>>
>> Ah, eso es cosa de C.L. Martínez ;-)
>>
>> Saludos,
>>
>> --
>
> Mira aquí tienes un ejemplo a nivel de cluster de storage:
>
> http://gluster.org/community/documentation/index.php/Gluster_3.2:_Exploring_Geo-replication_Deployment_Scenarios
>
> En tu caso es hacer lo mismo pero a nivel de servicio ... Para ello lo
> idela es que el ISP te diese un acceso de nivel 2 (y amazon también),
> es lo que se hace para desplegar por ejemplo firewalls geolocalizados
> (vamos que físicamente se encuentran a kilómetros de distancia). Si
> no, se puede trabajar también a nivel 3 (o sea IPs) via multicast.
>
> Saludos.
Mira un ejemplo más concreto utilizando SLES 11 SP3:
https://www.suse.com/documentation/sle_ha/singlehtml/book_sleha/book_sleha.html#cha.ha.geo.
Aunque yo creo que también se podría hacer con Debian pero no lo sé ...
Reply to: