[EMAIL PROTECTED] escribió:
> Me parece que realmente tu pregunta tiene mucho más de fondo.
>
> Son las aplicaciones y su ambiente las que se pueden llegar a tener el
> "título " de alta disponibilidad.
>
> Es el propio dueño de la aplicación quien define el grado de criticidad de
> su aplicación, actualmente antes que pensar en el número de nueves de
> disponibilidad, las empresas piensan en dos puntos: el RTO y el RPO
>
> RTO es el Recovery Time Objective, es decir, cuánto tiempo puede pasar
> desde que la aplicación deja de estar disponible hasta que puedes
> levantarla en el mismo o en otro sistema.
>
> RPO es el Recovery Point Objective y se refiere al punto en el tiempo en
> el que quieres recuperar tu información.
>
> Voy a poner un ejemplo, soy una compañia para la cual una aplicación es
> crítica, y determino un RTO de 1 hr, es decir, si por cualquier cuasa mi
> aplicación sufre algún problema debo ponerla en funcionamiento antes de 1
> hr.
>
>
> SI determino un RPO de 30 min, quiere decir que una vez que levante mi
> aplicación después de la caída, yo quiero y debo asegurar que la
> información está consistente hasta al menos 30 min antes del problema,
> aquí estoy considerando que estoy aceptando perder los últimos 30 min de
> cambios en el sistema.
>
>
> Ahora estos valores son altos, si quieres bajarlos a cerca de 0, entonces
> tienes que invertir muchísimo en infraestructura, planes, operatividad y
> varias cosas más.
>
> Actualmente si hablas de disponibilidad, creo que los puntos que debes
> cubrir son:
>
>
> A nivel de Site:
> - Sistemas contra incendios, contra temblores, contra inundaciones
> - Lo principal, un site redundante a la distancia que te permita llevarte
> tu producción a un lugar lejano, en caso de por ejemplo una huelga, dicho
> site debe incluir además la capacidad para mover todo tu equipo d
> etrabajo, es decir, no únicamente el site, también las instalaciones para
> que todo tu equipo de sistemas pueda moverse para allá
>
>
> Cluster
> - Obviamente establecer un ambiente de cluster, esto aplica no sólo para
> cuando un equipo falla, sino aplica también apara procedimientos normales,
> Por ejemplo si vas a aplicar parches, pues mueves los servicios del
> cluster a un sólo nodo, aplicas parches o cambios sobre los demás y luego
> vas moviendo los recursos a los otros nodos sin perder nunca
> disponibilidad
>
> Replicación
> - Obviamente si tienes un site remoto, pues necesitar replicar al
> información a él. la más fácil desde luego cintas, pero eso eleva tu RTO
> muchísimo, hoy día existen tecnologías a nivel de cajas de discos que
> permiten estar replicando constantemente la información de tus
> aplicaciones y levantar la aplicación en el site remoto con diferencia de
> minutos, obviamente, mientras más quieras replicar y más rápido es mucho
> más caro.
>
> Respaldos.
> - Nunca deben de faltar, aunque tengas replicación.
A propósito de respaldos y RTO, toma en cuenta tus planes de respaldo y
recuperación y las
ventanas de tiempo asociadas, en particular la ventana de recuperación. Una
pregunta que
te sirve (informalmente) para dimensionarla es la siguiente:
En caso de una caída crítica, que requiere de recuperar los respaldos, ¿cuánto
tiempo
tienes antes de empezar a buscar trabajo? :)
Esto es porque en respaldo es muy fácil estirar el tema tratando de respaldar
lo más
rápido posible, sacando respaldos full en forma muy esporádica, y rellenando el
resto del
tiempo con incrementales, pero a la hora de recuperar, si tu RTO es corto, no
tienes
tiempo de recuperar el full mas el cerro de incrementales, lo que hace que el
set de
respaldo sea básicamente inútil (ha pasado más de una vez en el mundo real).
Otro punto importante: de vez en cuando prueba los respaldos. También ha pasado
que todo
el proceso anda bien, pero a la hora de la recuperación las cintas no son
legibles.
> Plan de recuperación de desastres
> - este plan incluye los procedimientos de replicación, incluye tambipen
> quiénes y en qué tiempos se determina "desastre" y empieza a aplicar el
> plan.
> - Este plan es complejo, incluye también, quienes deben hacer los cambios,
> en qué orden deben levantarse las aplicaciones en el site alterno.
> - Algo bien importante, al menos 1 vez al año, probar el DRP.
>
> Al menos de momento es lo que se me viene a la mente, son muchpisimas
> cosas más, pero espero puedan darte una idea.
>
>
>
>
>
>
>
>
>
--
Julio Pacheco T.
Consultor Tecnológico
ProVectis S.A.
From [EMAIL PROTECTED] Tue Oct 17 12:53:10 2006
From: [EMAIL PROTECTED] (Fabian Alejandro)
Date: Tue Oct 17 14:44:52 2006
Subject: Como montar un mp4 player?
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
On 10/12/06, Maximiliano Marin Bustos <[EMAIL PROTECTED]> wrote:
> Estimados:
> Estoy corriendo debian sarge con el kernel 2.6.18 y necesito montar un MP4
> Player. He intentado con mount /media/sda y nada..
>
> Alguien lo ha hecho y sabe como hacerlo??
tenes creado /dev/sda ?
mi pendrive se cuelga de /dev/sda, pero mi maquina de fotos se cuelga
de /dev/sda1, creo que es por algo de la tabla de particiones.
Saludos.
From [EMAIL PROTECTED] Tue Oct 17 15:06:31 2006
From: [EMAIL PROTECTED] ([EMAIL PROTECTED])
Date: Tue Oct 17 16:04:41 2006
Subject: Problemas en la red
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
smokeping
saludos
> On 10/14/06, juan carlos mardones <[EMAIL PROTECTED]> wrote:
>> Buenas lista, no se si esto es offttopic o no, pero igual preguntare,
>> ya que no pierdo nada (espero que no me envien a /dev/null nomas ),
>> les cuento:
>> Hace unas semanas que estamos teniendo problemas en nuestra red, lo
>> mas probable es que vengan desde nuestro proveedor de conexion. Lo que
>> me pidieron para solucionar el problema es tener algun registro, ojala
>> en una base de datos que me permita generar estadisticas para por
>> ejemplo ver cuantas veces en el dia se cae, a que hora del dia se cae
>> mas, etc.
>>
>> Esquema de red:
>>
>> switchs cisco catalyst 2950 >> firewall >> Lab 1 (20 maquinas) - Lab
>> 2 (25 maquinas)
>>
>> en el firewall (ubuntu server 6.06 con todo al dia) tengo corriendo
>> ntop para observar el trafico del laboratorio y ademas mrtg para
>> echarle un miro al switch, tambien en el firewall tengo corriendo
>> apache para el mrtg (si, es insano colocar eso en el firewall, pero
>> esta dropeado el trafico por el puerto 80 salvo a una ip en
>> particular, ademas no tenia otra opcion.)
>> La cuestion es que estos programillas (ntop y mrtg) solo me generan
>> graficos y requiero numeros tangibles ...en realidad mi jefe pide
>> eso...
>>
>> La unica solucion que se me ocurrio, que por lo demas no es muy buena,
>> es realizar un script que:
>> 1.- haga ping a una maquina, por ejemplo a google y guarde el
>> resultado en un archivo
>> 2.- analizar el archivo (grep, awk, etc) y ver si se desconecta.
>>
>> el problema de este script es que no entrega timestamps que me pueda
>> decir a que hora no hay coneccion.
>>
>> Alguna sugerencia que me pueda ayudar a solucionar mi problema?, Algun
>> software (FSOSS) que me permita hacer eso?
>> Saludos, gracias por su tiempo (siempre es bueno dar las gracias por
>> el tiempo que ocuparon en leer mi e-mail), y perdonen si la pregunta
>> es OFF-TOPIC.
>>
>
> mmhhhh nagios te servira?... www.nagios.org... no se con certeza si te
> entrega la informacion y q tan bonita, pero de seguro te genera algun
> log que te sirva dsps.
>
> Saludos!
>
>
