oles@ovh.net
13/05/2008, 23:26
Buenos días,
Mañana jueves a última hora, todos los trabajos en los RPS 197 estarán terminados.
A partir de ahí, una vez estabilizada la plataforma, vamos a retomar los proyectos de RPS en curso :
- el RPS 2 (ya tenemos 100 RPS 2 que hace ping para empezar) : Deberíamos terminar el paso automático de RPS1 a RPS2. Luego vamos a permitir la contratación de RPS2. En el manager, se contratará un RPS2 y luego se dice "quiero pasar de RPS1 a RPS2", y estará hecho en 3 minutos. Los translados sólo se permitirán con el iSCSI v2
- el iSCSI v2 : ya está en marcha para todos los nuevos clientes a partir de hoy y los que realicen reinstalaciones. Para el resto, se hará un tránsito transparente en 3-4 semanas.
- el NFS : las pruebas han terminado y ya está listo para comenzar a funcionar. ¿Decimos la semana próxima? Vamos a ver... Hace falta también que terminemos la puesta en marcha del sistema de versiones (snap) a partir del Manager.
- Hemos reparado correctamente el problema de MAC en los servidores de ficheros (filers).
- Queda aún un problema a reparar en el target iSCSI bajo Solaris. Existe un bug que hace que el target del iSCSI se bloquee. A partir de ahí, la comunicación entre el SAN y los proxy iSCSI se corta, los servidores iSCSI lo detectan y se hacen un harakiri (kernel panic). Esto evitaba el paso en RO de los RPS. Para reparar el problema hemos realizado varias tareas :
** reparchear el kernel de los proxy iSCSI para añadir sleeps en lugar del kernel panic y hacer algo limplio.
** hemos encontrado un bug en el target del iSCSI que ha sido corregido en la última versión de openSolaris. Hemos solicitado a SUN de hacer un backport del parche a Solaris (como hicieron para el NFS). Es probablemente debido al hecho de que ZFS utiliza toda la RAM del servidor de ficheros (incluso con 64GB de RAM, ocupa el 80% de RAM) y a veces el iSCSI necesita de golpe y de forma inmediata mucha más RAM. La liberación es lenta y el target se bloquea. El target se reinicia automáticamente sólo una vez cada 3-4 semanas, pero esto es suficiente para bloquear el proxy.
** trabajamos en el backup personal sobre iSCSI v2. El objetivo es de "hacer clic aquí en el Mananger para tener un backup now" y/o "programar un backup tal día de la semana". Guardaríamos los 2 últimos backups de cada servidor, accesibles por FTP. No queda más que programarlo.
Un saludo
Octave
Mañana jueves a última hora, todos los trabajos en los RPS 197 estarán terminados.
A partir de ahí, una vez estabilizada la plataforma, vamos a retomar los proyectos de RPS en curso :
- el RPS 2 (ya tenemos 100 RPS 2 que hace ping para empezar) : Deberíamos terminar el paso automático de RPS1 a RPS2. Luego vamos a permitir la contratación de RPS2. En el manager, se contratará un RPS2 y luego se dice "quiero pasar de RPS1 a RPS2", y estará hecho en 3 minutos. Los translados sólo se permitirán con el iSCSI v2
- el iSCSI v2 : ya está en marcha para todos los nuevos clientes a partir de hoy y los que realicen reinstalaciones. Para el resto, se hará un tránsito transparente en 3-4 semanas.
- el NFS : las pruebas han terminado y ya está listo para comenzar a funcionar. ¿Decimos la semana próxima? Vamos a ver... Hace falta también que terminemos la puesta en marcha del sistema de versiones (snap) a partir del Manager.
- Hemos reparado correctamente el problema de MAC en los servidores de ficheros (filers).
- Queda aún un problema a reparar en el target iSCSI bajo Solaris. Existe un bug que hace que el target del iSCSI se bloquee. A partir de ahí, la comunicación entre el SAN y los proxy iSCSI se corta, los servidores iSCSI lo detectan y se hacen un harakiri (kernel panic). Esto evitaba el paso en RO de los RPS. Para reparar el problema hemos realizado varias tareas :
** reparchear el kernel de los proxy iSCSI para añadir sleeps en lugar del kernel panic y hacer algo limplio.
** hemos encontrado un bug en el target del iSCSI que ha sido corregido en la última versión de openSolaris. Hemos solicitado a SUN de hacer un backport del parche a Solaris (como hicieron para el NFS). Es probablemente debido al hecho de que ZFS utiliza toda la RAM del servidor de ficheros (incluso con 64GB de RAM, ocupa el 80% de RAM) y a veces el iSCSI necesita de golpe y de forma inmediata mucha más RAM. La liberación es lenta y el target se bloquea. El target se reinicia automáticamente sólo una vez cada 3-4 semanas, pero esto es suficiente para bloquear el proxy.
** trabajamos en el backup personal sobre iSCSI v2. El objetivo es de "hacer clic aquí en el Mananger para tener un backup now" y/o "programar un backup tal día de la semana". Guardaríamos los 2 últimos backups de cada servidor, accesibles por FTP. No queda más que programarlo.
Un saludo
Octave