Haciendo probaturas con el RAID he instalado una SLES 9 eval en una cutre-maquina (PIII en placa VIA mini-atx). Para probar el tema del RAID le he puesto un par de discos Maxtor de 80GB igualitos. He seguido las instrucciones del manual de SUSE y leído además los hilos de la lista que refieren a ello; sin embargo hay algunas cosas que no me quedan claras: 1- En disco1 el particionador de YaST _me obliga_ a definir, como mínimo, una partición /swap y otra /boot. El resto de disco es el que pongo como "partición sin formatear y tipo 0xFD Linux RAID. Evidentemente, después creo el RAID tipo 1 en ambos discos. Pero claro... el disco2 es copia (en este caso) de la tercera particion del disco 1. O sea que estoy haciendo espejo de todo el árbol exceptuando /swap y /boot, que el sistema me ha obligado ha particionar de manera "clásica". ¿Significa esto que disco2 no tiene /swap y /boot? Porqué si así es no entiendo demasiado bien cómo será funcional el disco2 en caso de que disco1 se joda. 2- Si monto un sistema que necesite, por ejemplo, 5-6 particiones (/swap, /boot/, /home, /srv, /var, /tmp) ¿como haría entonces el tema del RAID 1 si, precisamente, el sistema me obliga a la opción No formatear+ Linux RAID para poder crear el espejo? La verdad es que no lo entiendo. 3- Suponiendo además que los dos anteriores puntos se solucionan, todavía veo un inconveniente. Al estar el RAID montado en discos IDE, si el primario peta tengo un problema Houston, pues evidentemente en el montaje físico de los discos he puesto los jumpers para que definan cuál es el primario y cuál el secundario. Es decir, si el primario peta, por mucho que el secundario esté preparado para substituirlo, la máquina volverá a buscar el primario para arrancar. ¿?¿?¿?¿ Supongo que esto servirá; ahí va el resultado de fdisk -l ---------------------- Disco /dev/hda: 81.9 GB, 81964302336 bytes 16 cabezas, 63 sectores/pista, 158816 cilindros Unidades = cilindros de 1008 * 512 = 516096 bytes Disposit. Boot Start End Blocks Id System /dev/hda1 1 4064 2048224+ 82 Linux swap /dev/hda2 * 4065 4572 256032 83 Linux /dev/hda3 4573 158816 77738976 fd Linux raid autodetect Disco /dev/hdb: 81.9 GB, 81964302336 bytes 16 cabezas, 63 sectores/pista, 158816 cilindros Unidades = cilindros de 1008 * 512 = 516096 bytes Disposit. Boot Start End Blocks Id System /dev/hdb1 1 158816 80043232+ fd Linux raid autodetect Disco /dev/md0: 79.6 GB, 79604613120 bytes 2 cabezas, 4 sectores/pista, 19434720 cilindros Unidades = cilindros de 8 * 512 = 4096 bytes El disco /dev/md0 no contiene un tabla de particines válida. --------------------------- Me tiene inquietado especialmente el último comentario del comando acerca de la falta de tabla de particiones válida en el dispositivo RAID. Gracias por adelantado. -- Salut, Jordi Espasa
El Jueves, 9 de Febrero de 2006 17:27, Jordi Espasa Clofent escribió:
Evidentemente, después creo el RAID tipo 1 en ambos discos. Pero claro... el disco2 es copia (en este caso) de la tercera particion del disco 1. O sea que estoy haciendo espejo de todo el árbol exceptuando /swap y /boot, que el sistema me ha obligado ha particionar de manera "clásica".
Puedes definir varias particiones RAID. Es decir /dev/md0, /dev/md1, etc... Y a cada una le asocias un punto de montaje: /boot, /home , / etc...
2- Si monto un sistema que necesite, por ejemplo, 5-6 particiones (/swap, /boot/, /home, /srv, /var, /tmp) ¿como haría entonces el tema del RAID 1 si, precisamente, el sistema me obliga a la opción No formatear+ Linux RAID para poder crear el espejo?
Pues la solución es precisamente crear varias particiones RAID, tantas como necesites. Y a cada una de ellas le defines un punto de montaje. Por ejemplo, si quisieras crear una partición /, una partición /boot y otra /home. Pues deberías crear esas tres particiones en cada uno de los dos discos, todas ellas de tipo Linux RAID y del tamaño que te interese cada una de ellas (teniendo en cuenta que sean iguales dos a dos: es decir, las dos /home del mismo tamaño, las dos /boot del mismo tamaño...). Luego en YaST pinchas en el botón "crear RAID" (o algo similar) y vas seleccionando las particiones que contendrá cada uno de los /dev/mdx y defines el punto de montaje y el tipo de sistema de ficheros. Al final te quedarán líneas en /etc/fstab parecidas a las siguientes: /dev/md1 / ext3 acl,user_xattr 1 1 /dev/md0 /boot ext3 acl,user_xattr 1 2 /dev/md2 /home xfs defaults 1 2 Así en realidad lo que se tienen son tres dispositivos RAID. Por lo que leí en la lista quizás fuese posible subdividir una sola partición RAID en varias particiones (/, /home, /boot...) pero yo no fui capaz, así que opté por hacer una partición RAID para cada partición "normal" (/ , /home , /boot...)
3- Suponiendo además que los dos anteriores puntos se solucionan, todavía veo un inconveniente. Al estar el RAID montado en discos IDE, si el primario peta tengo un problema Houston, pues evidentemente en el montaje físico de los discos he puesto los jumpers para que definan cuál es el primario y cuál el secundario.
Es decir, si el primario peta, por mucho que el secundario esté preparado para substituirlo, la máquina volverá a buscar el primario para arrancar.
¿?¿?¿?¿
A esto no te sé responder con exactitud, pues mis discos son diferentes. Yo lo tengo montado con discos SATA, sin tener que definir primario ni esclavo con jumpers, aunque en la BIOS de la controladora SATA sí tengo definido cuál de los dos es el disco de arranque. Y desde luego, cuando desconecto el disco de arranque, arranca con el otro sin problemas.... Supongo que en tu caso debería ser igual, pero tampoco me hagas mucho caso en esto :-) Un saludo.
Por ejemplo, si quisieras crear una partición /, una partición /boot y otra /home. Pues deberías crear esas tres particiones en cada uno de los dos discos, todas ellas de tipo Linux RAID y del tamaño que te interese cada una de ellas (teniendo en cuenta que sean iguales dos a dos: es decir, las dos /home del mismo tamaño, las dos /boot del mismo tamaño...). Luego en YaST pinchas en el botón "crear RAID" (o algo similar) y vas seleccionando las particiones que contendrá cada uno de los /dev/mdx y defines el punto de montaje y el tipo de sistema de ficheros.
Ya, pues debo ser un poco cazurro (que lo soy) porqué lo he intentado y no hay manera. Lo hago tal y como dices, pero después, al "Crear Raid" sólo me deja definir un sólo punto de montaje, por muchas particiones RAID que haya hecho. De todas maneras supongo que me estoy equivocando en alguna chorrada de manejo de YaST, así que le volveré a meter caña.
Al final te quedarán líneas en /etc/fstab parecidas a las siguientes:
/dev/md1 / ext3 acl,user_xattr 1 1 /dev/md0 /boot ext3 acl,user_xattr 1 2 /dev/md2 /home xfs defaults 1 2
Así en realidad lo que se tienen son tres dispositivos RAID.
Ajá.
Por lo que leí en la lista quizás fuese posible subdividir una sola partición RAID en varias particiones (/, /home, /boot...) pero yo no fui capaz, así que opté por hacer una partición RAID para cada partición "normal" (/ , /home , /boot...)
Pues yo me perdí ese hilo entonces :(
3- Suponiendo además que los dos anteriores puntos se solucionan, todavía veo un inconveniente. Al estar el RAID montado en discos IDE, si el primario peta tengo un problema Houston, pues evidentemente en el montaje físico de los discos he puesto los jumpers para que definan cuál es el primario y cuál el secundario.
Es decir, si el primario peta, por mucho que el secundario esté preparado para substituirlo, la máquina volverá a buscar el primario para arrancar.
¿?¿?¿?¿
A esto no te sé responder con exactitud, pues mis discos son diferentes. Yo lo tengo montado con discos SATA, sin tener que definir primario ni esclavo con jumpers, aunque en la BIOS de la controladora SATA sí tengo definido cuál de los dos es el disco de arranque. Y desde luego, cuando desconecto el disco de arranque, arranca con el otro sin problemas.... Supongo que en tu caso debería ser igual, pero tampoco me hagas mucho caso en esto :-)
Buscaré más info a ver si doy con ello. Gracias por todo ;) -- Salut, Jordi Espasa
On Thursday 09 February 2006 17.27, Jordi Espasa Clofent wrote:
Haciendo probaturas con el RAID he instalado una SLES 9 eval en una cutre-maquina (PIII en placa VIA mini-atx). Para probar el tema del RAID le he puesto un par de discos Maxtor de 80GB igualitos.
<snip>
La verdad es que no lo entiendo.
3- Suponiendo además que los dos anteriores puntos se solucionan, todavía veo un inconveniente. Al estar el RAID montado en discos IDE, si el primario peta tengo un problema Houston, pues evidentemente en el montaje físico de los discos he puesto los jumpers para que definan cuál es el primario y cuál el secundario.
Es decir, si el primario peta, por mucho que el secundario esté preparado para substituirlo, la máquina volverá a buscar el primario para arrancar.
<snip> Para tu pueba de software raid tienes que saber algo mas. No hace sentido poner los dos discos en la misma cinta de IDE. El systema IDE solo puede hablar con un disco ala ves, hacique todas las adventajas del raid (con exception de los datos dobles) se pierden. Si lo haces haci, tu particion de raid sera mas lenta que un disco solo, en ves de mas rapido! Ademas es bueno saber, que si te muere un disco con particion de swap montado, se te va morir el systema (puncto). Quando el systema vuelva a subir, sube sin la particion de swap en el disco roto. Hacique el IDE soft-raid te da la seguridad del redundancia de datos, por no el "100% uptime" de un system de hardware raid (caro). Jerry
Hola :) El Viernes, 10 de Febrero de 2006 08:25, Jerry Westrick escribió:
On Thursday 09 February 2006 17.27, Jordi Espasa Clofent wrote:
Haciendo probaturas con el RAID he instalado una SLES 9 eval en una cutre-maquina (PIII en placa VIA mini-atx). Para probar el tema del RAID le he puesto un par de discos Maxtor de 80GB igualitos.
<snip>
La verdad es que no lo entiendo.
3- Suponiendo además que los dos anteriores puntos se solucionan, todavía veo un inconveniente. Al estar el RAID montado en discos IDE, si el primario peta tengo un problema Houston, pues evidentemente en el montaje físico de los discos he puesto los jumpers para que definan cuál es el primario y cuál el secundario.
Es decir, si el primario peta, por mucho que el secundario esté preparado para substituirlo, la máquina volverá a buscar el primario para arrancar.
<snip>
Para tu pueba de software raid tienes que saber algo mas. No hace sentido poner los dos discos en la misma cinta de IDE. El systema IDE solo puede hablar con un disco ala ves, hacique todas las adventajas del raid (con exception de los datos dobles) se pierden.
Si lo haces haci, tu particion de raid sera mas lenta que un disco solo, en ves de mas rapido!
Ademas es bueno saber, que si te muere un disco con particion de swap montado, se te va morir el systema (puncto). Quando el systema vuelva a subir, sube sin la particion de swap en el disco roto.
Hacique el IDE soft-raid te da la seguridad del redundancia de datos, por no el "100% uptime" de un system de hardware raid (caro).
Estoy de acuerdo con Jerry. En el caso de RAID, a mi personalmente me gusta meter /home en RAID, pero no el sistema (/). Esto se debe a que si actualizo algo que no funciona (un parche malo o un error de configuración, ...) se me duplica en ambos discos. En cambio, prefiero hacer imágenes de / a otro disco (o un fichero) y, si falla algo ... restaurar la imagen. De esta manera me aseguro que no "me cargo el equipo". Obviamente, esto puede producir un downtime, pero es bastante más pequeño a si tengo que reinstalar todo. IMHO Rafa PD Carlos ... échale un vistazo a las cabeceras de este correo !!! ;) Por fin :) -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com
Estoy de acuerdo con Jerry.
En el caso de RAID, a mi personalmente me gusta meter /home en RAID, pero no el sistema (/). Esto se debe a que si actualizo algo que no funciona (un parche malo o un error de configuración, ...) se me duplica en ambos discos.
Si claro. En mi caso en particular el objetivo es crear un espejo completo del disco primero. Evidentemente después, en caso de montarlo en una máquina en producción, se tienen que tener en cuenta ese detalle y todos los demás.
En cambio, prefiero hacer imágenes de / a otro disco (o un fichero) y, si falla algo ... restaurar la imagen. De esta manera me aseguro que no "me cargo el equipo". Obviamente, esto puede producir un downtime, pero es bastante más pequeño a si tengo que reinstalar todo.
Correcto. ¿Y que haces, tiras de dd a saco (lo digo porqué hablas de "imagen")?
PD Carlos ... échale un vistazo a las cabeceras de este correo !!! ;)
¿Qué les pasa? Es que soy profano aún en el tema este...
Hola :) El Viernes, 10 de Febrero de 2006 09:13, Jordi Espasa Clofent escribió:
Estoy de acuerdo con Jerry.
En el caso de RAID, a mi personalmente me gusta meter /home en RAID, pero no el sistema (/). Esto se debe a que si actualizo algo que no funciona (un parche malo o un error de configuración, ...) se me duplica en ambos discos.
Si claro. En mi caso en particular el objetivo es crear un espejo completo del disco primero. Evidentemente después, en caso de montarlo en una máquina en producción, se tienen que tener en cuenta ese detalle y todos los demás.
En cambio, prefiero hacer imágenes de / a otro disco (o un fichero) y, si falla algo ... restaurar la imagen. De esta manera me aseguro que no "me cargo el equipo". Obviamente, esto puede producir un downtime, pero es bastante más pequeño a si tengo que reinstalar todo.
Correcto. ¿Y que haces, tiras de dd a saco (lo digo porqué hablas de "imagen")?
Nosotros (SGI) usamos XFS que tiene una herramienta para clonar las particiones XFS (xfs_dump/xfs_restore) por lo que no tarda tanto 0:)
PD Carlos ... échale un vistazo a las cabeceras de este correo !!! ;)
¿Qué les pasa? Es que soy profano aún en el tema este...
Es que llevo desde mayo usando MS-Windows XP y por fin he podido migrar a Linux otra vez ... qué tranquilidad ;) Bromas de lado, el XP me estaba dando bastantes problemas, no estoy cómodo usándolo porque no lo sé usar: me parece complicado y nada "user friendly", no comprendo por qué no puedo obtener información del sistema cuando algo "pasa", estuve un mes con el MS-Outlook y ahora le tengo más miedo que a un nublado, no es configurable, no hace lo que yo le pido (o no lo sé pedir), para usar herramientas básicas y muy útiles para mi trabajo (ssh, rsync, ttcp, xdd, ...) necesito instalarme cygwin, ... No digo que MS-Windows XP sea malo, digo que para mi trabajo y para mi uso personal no me ofrece lo que yo necesito. Rafa -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com
Nosotros (SGI) usamos XFS que tiene una herramienta para clonar las particiones XFS (xfs_dump/xfs_restore) por lo que no tarda tanto 0:)
Interesante Rafa. He leído por ahí que XFS tiene una alta performance especialmente para tratar archivos grandes; le estoy dando vueltas a implantar XFS en la partición de un disco que me hará de FTP para archivos pedazo (ya sabes, ISOs y demás). Cuéntame que tal este filesystem y sus herramientas. Please, vaya... -- Salut, Jordi Espasa
Hola :) El Miércoles, 15 de Febrero de 2006 15:17, Jordi Espasa Clofent escribió:
Nosotros (SGI) usamos XFS que tiene una herramienta para clonar las particiones XFS (xfs_dump/xfs_restore) por lo que no tarda tanto 0:)
Interesante Rafa. He leído por ahí que XFS tiene una alta performance especialmente para tratar archivos grandes; le estoy dando vueltas a implantar XFS en la partición de un disco que me hará de FTP para archivos pedazo (ya sabes, ISOs y demás).
Cuéntame que tal este filesystem y sus herramientas. Please, vaya...
Yo lo llevo usando desde antes de entrar en SGI y me ha ido muy bien. Se diseñó para trabajar principalmente con ficheros grandes debido a los clientes que tenemos, pero funciona bien con ficheros "normales" (un par de MB). Si vas a trabajar con millones de ficheros pequeños (un par de KB) olvídate. Datos que te puedo pasar: - tenemos clientes con 70 millones de ficheros en un directorio y no han visto pérdida de rendimiento. Son ficheros de tamaño medio a grande (a partir de un par de MB) - el sistema de ficheros es capaz de escalar hasta un tamaño de 18 PetaBytes (18 millones de TB) - el tamaño máximo de fichero es de 9 PetaBytes (9 millones de TB) - tiene herramientas de defragmentación - tiene herramientas de redimensionado de sistema de ficheros en tiempo de ejecución, es decir, no tienes que desmontar el sistema de ficheros para agrandarlo. - tienes herramientas para sacar información y poder duplicar el "layout" del sistema de ficheros (tamaño de bloques, de allocation groups, ...) de forma que lo puedas duplicar y no tengas que andar recordando con qué opciones formateaste - tienes herramientas para clonar el sisitema de ficheros y restaurarlo Ahora mismo no se me ocurre nada más 0:) HTH Rafa -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman
Yo lo llevo usando desde antes de entrar en SGI y me ha ido muy bien. Se diseñó para trabajar principalmente con ficheros grandes debido a los clientes que tenemos, pero funciona bien con ficheros "normales" (un par de MB). Si vas a trabajar con millones de ficheros pequeños (un par de KB) olvídate. Datos que te puedo pasar: - tenemos clientes con 70 millones de ficheros en un directorio y no han visto pérdida de rendimiento. Son ficheros de tamaño medio a grande (a partir de un par de MB) - el sistema de ficheros es capaz de escalar hasta un tamaño de 18 PetaBytes (18 millones de TB) - el tamaño máximo de fichero es de 9 PetaBytes (9 millones de TB) - tiene herramientas de defragmentación - tiene herramientas de redimensionado de sistema de ficheros en tiempo de ejecución, es decir, no tienes que desmontar el sistema de ficheros para agrandarlo.
Ostia!!! Esto es realmente interesante. El otro día un colega de oficio me "vaciliba" y me decía que GNU/Linux es un niño comparado con los otros UNIX más veteranos. Y el ejempo que me puso fue precisamente este: "yo, con HP-UX redimensiono las particiones sin desmontar nada, en caliente y santas pascuas". Jejjeje cuando lo vea se lo diré.
- tienes herramientas para sacar información y poder duplicar el "layout" del sistema de ficheros (tamaño de bloques, de allocation groups, ...) de forma que lo puedas duplicar y no tengas que andar recordando con qué opciones formateaste
Si, he estado mirando la documentación de SGI y la retaíla de comandos disponibles tiene _muy_ buena pinta.
- tienes herramientas para clonar el sisitema de ficheros y restaurarlo
Esto es especialmente interesante si pensamos en equipos en producción. -- Salut, Jordi Espasa
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-10 a las 08:56 +0100, Rafa Grimán escribió:
En el caso de RAID, a mi personalmente me gusta meter /home en RAID, pero no el sistema (/). Esto se debe a que si actualizo algo que no funciona (un parche malo o un error de configuración, ...) se me duplica en ambos discos.
Hay una técnica que no se si es posible aquí, pero que la usabamos en ciertas maquinas grandes (unix-rtr). Consiste en desactivar la mitad de un espejo, y dejarla en standby. La actualización se hace únicamente sobre la mitad del espejo que queda funcionando en modo degradado. Si funciona, se activa de nuevo la otra mitad, y automáticamente se sincronizan. Si no funciona, para volver atrás - y he aquí el problema - hay que arrancar con el lado que estaba desactivado, dejando el lado actualizado (que es el más reciente) incativo; y luego hay que forzar la actualización desde el lado antiguo al nuevo, es decir, al revés de lo que sería normal. No se si me sigues :-?
PD Carlos ... échale un vistazo a las cabeceras de este correo !!! ;)
KMail :-)
Por fin :)
¿ha costado, ein? - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD7T8NtTMYHG2NR9URAk4WAJ96cy1W5GTPHbFB2JcPmHxE+dFQ5wCfb1Z/ 1cVZEwJfMyAkSSFUTbtp75E= =FO7R -----END PGP SIGNATURE-----
El 10/02/06, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE-----
Hay una técnica que no se si es posible aquí, pero que la usabamos en ciertas maquinas grandes (unix-rtr).
Consiste en desactivar la mitad de un espejo, y dejarla en standby. La actualización se hace únicamente sobre la mitad del espejo que queda funcionando en modo degradado. Si funciona, se activa de nuevo la otra mitad, y automáticamente se sincronizan.
Si no funciona, para volver atrás - y he aquí el problema - hay que arrancar con el lado que estaba desactivado, dejando el lado actualizado (que es el más reciente) incativo; y luego hay que forzar la actualización desde el lado antiguo al nuevo, es decir, al revés de lo que sería normal.
No se si me sigues :-?
mmm.. yo no !!!! te fuiste muy lejos... ahoras que tienes banda ancha !!! :-D salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-11 a las 00:42 -0300, Victor Hugo dos Santos escribió:
No se si me sigues :-?
mmm.. yo no !!!! te fuiste muy lejos... ahoras que tienes banda ancha !!! :-D
:-) Lo intento de nuevo. Tenemos dos discos en espejo, A y B. Paramos el A, quizás con algo del estilo de "mdadm /dev/md0 -r /dev/hda3" o "mdadm - --manage --set-faulty /dev/md0 /dev/hda3". Ojo, no se te ocurra probarlo así como así, porque todo esto es una elucubración mia en linux; se que existe en otras máquinas, pero no en linux. Entonces, tenemos un raid degradado con el lado B activo. Hacemos la actualización del sistema con el disco así, degradado. Si todo va bien, entonces volvemos a activar el lado A: "mdadm /dev/md0 - -a /dev/hda3". Se actualiza el espejo automáticamente, y santas pascuas. ¿Y si va mal? Bueno... esta es la parte que en Linux no existe: Habría que quitar el lado B - que no se va a dejar, porque es el único que queda. Habría que hacerlo desde un sistema de rescate, a raid parado, que forzara el lado A como activo, y entonces añadiera el lado B, que es el que tiene la actualización. Al reponerse el espejo se copiaría el lado A sobre el B - - al contrario de lo que haría el software del raid por su cuenta. La única manera que se me ocurre de forzarlo sería formatear el lado B... como si el lado B se hubiera destruido físicamente, por lo que el raid no tendría más remedio que copiar el A sobre el B vacío. Si tuviera un raid disponible, lo probaba. Pero creo que no puedo. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD8KSDtTMYHG2NR9URAjsyAJ4kCDkZS11Hrzi3pCT1ZJC9oGl9oQCeLWSw mv+HLbAN0MnMOPCO58ySKg4= =yXc7 -----END PGP SIGNATURE-----
Hola :) El Sábado, 11 de Febrero de 2006 02:34, Carlos E. R. escribió:
El 2006-02-10 a las 08:56 +0100, Rafa Grim�n escribi�:
En el caso de RAID, a mi personalmente me gusta meter /home en RAID, pero no el sistema (/). Esto se debe a que si actualizo algo que no funciona (un parche malo o un error de configuraci�n, ...) se me duplica en ambos discos.
Hay una t�cnica que no se si es posible aqu�, pero que la usabamos en ciertas maquinas grandes (unix-rtr).
Consiste en desactivar la mitad de un espejo, y dejarla en standby. La actualizaci�n se hace �nicamente sobre la mitad del espejo que queda funcionando en modo degradado. Si funciona, se activa de nuevo la otra mitad, y autom�ticamente se sincronizan.
Que yo sepa, esto no existe en Linux :( Estaría bien esta característica.
Si no funciona, para volver atr�s - y he aqu� el problema - hay que arrancar con el lado que estaba desactivado, dejando el lado actualizado (que es el m�s reciente) incativo; y luego hay que forzar la actualizaci�n desde el lado antiguo al nuevo, es decir, al rev�s de lo que ser�a normal.
Una preguntilla, ¿esto era todo "digital" (aka con los dedos y tecleando)? Es decir, ¿había un admin/sysop que lo hacía o bien el propio sistema lo tenía automatizado?
No se si me sigues :-?
PD Carlos ... �chale un vistazo a las cabeceras de este correo !!! ;)
KMail :-)
Por fin :)
�ha costado, ein?
Ha valido la espera ;) Por cierto, hay que celebrar lo de tu ADSL !! ;) -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-13 a las 10:22 +0100, Rafa Grimán escribió:
Consiste en desactivar la mitad de un espejo, y dejarla en standby. La actualizaci[f3]n se hace [fa]nicamente sobre la mitad del espejo que queda funcionando en modo degradado. Si funciona, se activa de nuevo la otra mitad, y autom[e1]ticamente se sincronizan.
Que yo sepa, esto no existe en Linux :( Estaría bien esta característica.
Desde luego. Yo creo que sería posible, pero... no tengo manera de experimentarlo. Creo que haría falta el concurso de un sistema de rescate manual para forzar el cambio.
Una preguntilla, ¿esto era todo "digital" (aka con los dedos y tecleando)? Es decir, ¿había un admin/sysop que lo hacía o bien el propio sistema lo tenía automatizado?
Con los dedos, y con alguien de soporte de nivel superior pegado a la oreja :-p ¡Buf! Tampoco lo hacían siempre... creo que era con los upgrades de nivel, no con los parches normalitos. Estos también tenían un procedimiento de backout: los parches primero se cargaban, luego se activaban una noche, y si a las 24 horas no se veían problemas, se dejaban definitivos. Si no, con un simple comando se restituía la versión anterior, que no estaba borrada. Ten en cuenta que al desactivar un lado del espejo dejas la máquina vulnerable a fallos de disco, y ya sabes que Murphy nunca duerme ;-) La primera vez que lo vi fué durante un curso especial, que la máquina de pruebas (maqueta) tenían una mitad con una release y la otra mitad con la siguiente. Medio dia trabajaba con uno, y el otro medio con el otro, para que los desarrolladores resolvieran los problemas en que habían estado trabajando la mañana... alucinante. Todo ello para poder hacer el cambio a los clientes sin problemas.
Ha valido la espera ;) Por cierto, hay que celebrar lo de tu ADSL !! ;)
:-) Pero no olvidemos que hay mucha gente que no puede, incluso en España. A mi los de Ono (cableros) me mandaron a freir monas, y eso que vivo en una ciudad importante y tengo un registro de ono a 20 metros de mi puerta. Peor los tienen los de los pueblos, que de adsl nada de nada. Ya les podían al menos ofrecer rdsi a precio barato. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD8I7ItTMYHG2NR9URAnBTAJ4mjeuhmRX60t0Hb1LMInidABNkrwCgmGO4 8c/6oxpSvxfc1X2/Oz+R2OI= =JlEh -----END PGP SIGNATURE-----
Hola :) El Lunes, 13 de Febrero de 2006 14:50, Carlos E. R. escribió:
El 2006-02-13 a las 10:22 +0100, Rafa Grim�n escribi�:
Consiste en desactivar la mitad de un espejo, y dejarla en standby. La actualizaci[f3]n se hace [fa]nicamente sobre la mitad del espejo que queda funcionando en modo degradado. Si funciona, se activa de nuevo la otra mitad, y autom[e1]ticamente se sincronizan.
Que yo sepa, esto no existe en Linux :( Estar�a bien esta caracter�stica.
Desde luego.
Yo creo que ser�a posible, pero... no tengo manera de experimentarlo. Creo que har�a falta el concurso de un sistema de rescate manual para forzar el cambio.
Una preguntilla, �esto era todo "digital" (aka con los dedos y tecleando)? Es decir, �hab�a un admin/sysop que lo hac�a o bien el propio sistema lo ten�a automatizado?
Con los dedos, y con alguien de soporte de nivel superior pegado a la oreja :-p
Ya, "trabajo en equipo" ;)
�Buf!
Tampoco lo hac�an siempre... creo que era con los upgrades de nivel, no con los parches normalitos. Estos tambi�n ten�an un procedimiento de backout: los parches primero se cargaban, luego se activaban una noche, y
En el caso de Irix, existe la opción de rollback de un parche por si lo has instalado y te falla el sistema. Estaría bien que los sistemas de paquetes de Linux tuvieran algo de eso. No me refiero a la opción: rpm --oldpackage (reinstalar un paquete viejo) Sino que le puedes decir al sistema de paquetes que haga un rollback y lo que hace es eliminar lo que ha añadido.
si a las 24 horas no se ve�an problemas, se dejaban definitivos. Si no, con un simple comando se restitu�a la versi�n anterior, que no estaba borrada.
Ten en cuenta que al desactivar un lado del espejo dejas la m�quina vulnerable a fallos de disco, y ya sabes que Murphy nunca duerme ;-)
Es que Murphy es un currante nato ;)
La primera vez que lo vi fu� durante un curso especial, que la m�quina de pruebas (maqueta) ten�an una mitad con una release y la otra mitad con la siguiente. Medio dia trabajaba con uno, y el otro medio con el otro, para que los desarrolladores resolvieran los problemas en que hab�an estado trabajando la ma�ana... alucinante. Todo ello para poder hacer el cambio a los clientes sin problemas.
Ahora con Xen, VMWare y similares tienes la posibilidad de trabajar con máquinas virtuales y te ahorras ese ajetreo. Lo bueno de la virtualización es poder hacer snapshots, migrar entre máquinas físicas, ... Parece que Xen ha impulsado bastante el tema y se está consiguiendo
Ha valido la espera ;) Por cierto, hay que celebrar lo de tu ADSL !! ;)
:-)
Pero no olvidemos que hay mucha gente que no puede, incluso en Espa�a. A mi los de Ono (cableros) me mandaron a freir monas, y eso que vivo en una ciudad importante y tengo un registro de ono a 20 metros de mi puerta. Peor los tienen los de los pueblos, que de adsl nada de nada. Ya les pod�an al menos ofrecer rdsi a precio barato.
Eso es verdad. Rafa -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-13 a las 15:35 +0100, Rafa Grimán escribió:
Con los dedos, y con alguien de soporte de nivel superior pegado a la oreja :-p
Ya, "trabajo en equipo" ;)
Y en extras, para que mole ;-)
En el caso de Irix, existe la opción de rollback de un parche por si lo has instalado y te falla el sistema. Estaría bien que los sistemas de paquetes de Linux tuvieran algo de eso.
No me refiero a la opción:
rpm --oldpackage
(reinstalar un paquete viejo)
Sino que le puedes decir al sistema de paquetes que haga un rollback y lo que hace es eliminar lo que ha añadido.
Exacto, a eso me refiero. Es una lástima no tener eso en Linux. Supone tener en el sistema todos los ficheros cambiados por el parche, bien en otra partición, bien en un tar. En otra partición o al menos, otro directorio, me parece más seguro. Y organizados de alguna forma tal, que el sistema sepa perfectamente que cosas son de cada paquete, y que con un simple comando se puedan restituir - incluso desde el sistema de rescate. Eso me recuerda... hace tiempo, cuando instalabas un parche rpm, el yast hacía una copia de seguridad en tgz de lo que machacaba. Sería para un backout manual. Creo que eso lo hacía el yast1, pero no el 2. Hablando de eso, también me recuerda que acaban de decir que el Yast cambia a otra generación en el 10.1 - integran yast y libredcarpet - y eso es un cambio para echarse a temblar. | Date: Thu, 09 Feb 2006 17:14:31 +0100 | From: Andreas Jaeger | Subject: [opensuse-announce] SUSE Linux 10.1 Update | | I'd like to give you an update on our beta process with the following | list of topics: | | ... | | Package Manager Major Changes | ============================= | | We're replacing our package manager resolver library with a new version | called "libzypp". | | libzypp is the integration of SUSE's yast2 Package manager and Ximian's | libredcarpet. At Novell we used two solutions so far - Red Carpet and | YaST package manager - and decided to merge both in a best of breed | approach. | |... El resto, pues en la lista de anuncios de opensuse, que al fin y al cabo, está en otro idioma ;-) También hablan de otro servidor X nuevo. ¡Digo! Pa'echarse a temblar.
otro, para que los desarrolladores resolvieran los problemas en que hab[ed]an estado trabajando la ma[f1]ana... alucinante. Todo ello para poder hacer el cambio a los clientes sin problemas.
Ahora con Xen, VMWare y similares tienes la posibilidad de trabajar con máquinas virtuales y te ahorras ese ajetreo. Lo bueno de la virtualización es poder hacer snapshots, migrar entre máquinas físicas, ...
Parece que Xen ha impulsado bastante el tema y se está consiguiendo
Si, es cierto. Pero en ese caso concreto mio, de centrales telefónicas, no es válido, porque hay que probar también el hardware - un hardware muy peculiar con ideas propias. Demasiado complejo. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD8KghtTMYHG2NR9URArKuAJ907vA98nBDd7vDQhP1RCTlOGC5awCfcAQq 7nDw3Q9XQZRdahQVrlo/u9w= =Spv/ -----END PGP SIGNATURE-----
Hola :) El Lunes, 13 de Febrero de 2006 16:39, Carlos E. R. escribió: [...]
Eso me recuerda... hace tiempo, cuando instalabas un parche rpm, el yast hac�a una copia de seguridad en tgz de lo que machacaba. Ser�a para un backout manual. Creo que eso lo hac�a el yast1, pero no el 2.
¡Qué memoria! Yo no me acuerdo 0:)
Hablando de eso, tambi�n me recuerda que acaban de decir que el Yast cambia a otra generaci�n en el 10.1 - integran yast y libredcarpet - y eso es un cambio para echarse a temblar.
No sé si será bueno o no. He usado Red Carpet y la verdad es que resuelve bien las dependencias, tienes línea de comando, ... pero vamos no me ha quitado el sueño. Es un sistema de paquetes similar a los que ya hay. Ya veremos .... [...]
También hablan de otro servidor X nuevo. �Digo! Pa'echarse a temblar.
Los vídeos que he visto son impresionantes. Como todo en esta vida, tiene sus ventajas e inconvenientes. Es muy potente (basado en OpenGL) y muy atractivo. Lo "malo" es que necesitas una tarjeta gráfica con aceleración por hardware por lo que los drivers libres no valen y aún no es un servidor X del todo.
otro, para que los desarrolladores resolvieran los problemas en que habían estado trabajando la mañana... alucinante. Todo ello para poder hacer el cambio a los clientes sin problemas.
Ahora con Xen, VMWare y similares tienes la posibilidad de trabajar con m�quinas virtuales y te ahorras ese ajetreo. Lo bueno de la virtualizaci�n es poder hacer snapshots, migrar entre m�quinas f�sicas, ...
Parece que Xen ha impulsado bastante el tema y se est� consiguiendo
Si, es cierto. Pero en ese caso concreto mio, de centrales telef�nicas, no es v�lido, porque hay que probar tambi�n el hardware - un hardware muy peculiar con ideas propias. Demasiado complejo.
Eso es cierto, hay algunos entornos en los que la virtualización no es interesante. En HPC ocurre lo mismo ... si virtualizas, quitas potencia a la máquina ... Rafa -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman
El 13/02/06, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE-----
[...]
Hablando de eso, también me recuerda que acaban de decir que el Yast cambia a otra generación en el 10.1 - integran yast y libredcarpet - y eso es un cambio para echarse a temblar.
mmmm.. alguna experiencia mala ??? he utilizado un poco redcarpet en novell desktop y la verdad es que me parecio uno software mas en los administradores de paquetes (lease urpmi, apt-get, yum) !!! pero mi experiencia con el, como eh dicho, fue muy poca !!! :-( [...]
El resto, pues en la lista de anuncios de opensuse, que al fin y al cabo, está en otro idioma ;-)
También hablan de otro servidor X nuevo. ¡Digo! Pa'echarse a temblar.
mmm.. se supone que en suse/opensuse ya vienen con xorg, que teoricamente seria el mas nuevo que hay en servidores X.... o te refieres a los escritorios 3d que ahora estan de moda ??? se es asi, lo veo escalafriante, ya que no todos tenemos tarjetas graficas con soporte (ati / nvidia) en linux !!! :-( bye -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-13 a las 15:53 -0300, Victor Hugo dos Santos escribió:
Hablando de eso, también me recuerda que acaban de decir que el Yast cambia a otra generación en el 10.1 - integran yast y libredcarpet - y eso es un cambio para echarse a temblar.
mmmm.. alguna experiencia mala ??? he utilizado un poco redcarpet en novell desktop y la verdad es que
No con eso; la del cambio del yast1 al Yast2 actual.
También hablan de otro servidor X nuevo. ¡Digo! Pa'echarse a temblar.
mmm.. se supone que en suse/opensuse ya vienen con xorg, que teoricamente seria el mas nuevo que hay en servidores X.... o te refieres a los escritorios 3d que ahora estan de moda ??? se es asi, lo veo escalafriante, ya que no todos tenemos tarjetas graficas con soporte (ati / nvidia) en linux !!! :-(
De esto: | XGL | === | | Xgl is an Xserver that uses OpenGL for its drawing operations. Xgl | engineer David Reveman has posted enhancements to Xgl and a new | compositor, 'Compiz' with a request that it be added to the | freedesktop.org CVS repository. Some operations like antialiased font | rendering is noticeably faster with this technology, and future | graphics hardware might only have support for 3D operations and no 2D | core any more. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD8N0PtTMYHG2NR9URAmeZAJ4vy+Rbo+s9izFEDkn7hxssys4GzACdHAdA J1tvpiQRAydrkGasxkGtVbQ= =Bc12 -----END PGP SIGNATURE-----
Hola :) El Lunes, 13 de Febrero de 2006 20:25, Carlos E. R. escribió: [...]
Tambi�n hablan de otro servidor X nuevo. �Digo! Pa'echarse a temblar.
mmm.. se supone que en suse/opensuse ya vienen con xorg, que teoricamente seria el mas nuevo que hay en servidores X.... o te refieres a los escritorios 3d que ahora estan de moda ??? se es asi, lo veo escalafriante, ya que no todos tenemos tarjetas graficas con soporte (ati / nvidia) en linux !!! :-(
De esto: | XGL | === | | Xgl is an Xserver that uses OpenGL for its drawing operations. Xgl | engineer David Reveman has posted enhancements to Xgl and a new | compositor, 'Compiz' with a request that it be added to the | freedesktop.org CVS repository. Some operations like antialiased font | rendering is noticeably faster with this technology, and future | graphics hardware might only have support for 3D operations and no 2D | core any more.
Este es el vídeo que comentaba que deberíais ver en otro correo, es impresionante :) Rafa -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman
Para tu pueba de software raid tienes que saber algo mas. No hace sentido poner los dos discos en la misma cinta de IDE. El systema IDE solo puede hablar con un disco ala ves, hacique todas las adventajas del raid (con exception de los datos dobles) se pierden.
Si lo haces haci, tu particion de raid sera mas lenta que un disco solo, en ves de mas rapido!
Si, lo leí en el Softwate-RAID-Howto; en este caso tampoco me preocupa demasiado. Es una máquina beta-tester para hacer pruebas. En este caso en particular prima el tema de la redundancia y no el tema de la performance. Sin embargo, entonces ¿sería lo más adecuado montar los discos en los diferentes canales IDE?
Ademas es bueno saber, que si te muere un disco con particion de swap montado, se te va morir el systema (puncto). Quando el systema vuelva a subir, sube sin la particion de swap en el disco roto.
Entiendo. ¿Y a esto como le pongo solución? ¿Creando también una partición /swap en el disco2 (el redundante)?
Hacique el IDE soft-raid te da la seguridad del redundancia de datos, por no el "100% uptime" de un system de hardware raid (caro).
Si, como casi siempre: lo más caro suele ser más eficiente. Aunque no es ley inequívoca, claro. ;)
On Friday 10 February 2006 09.10, Jordi Espasa Clofent wrote:
Sin embargo, entonces ¿sería lo más adecuado montar los discos en los diferentes canales IDE?
Si. como ejemplo hda (master canal uno) y hdc (master canal 2)
Ademas es bueno saber, que si te muere un disco con particion de swap montado, se te va morir el systema (puncto). Quando el systema vuelva a subir, sube sin la particion de swap en el disco roto.
Entiendo. ¿Y a esto como le pongo solución? ¿Creando también una partición /swap en el disco2 (el redundante)?
Haci lo hago yo. Cuando los dos discos funcionan tengo los dos swap montados.
Hacique el IDE soft-raid te da la seguridad del redundancia de datos, por no el "100% uptime" de un system de hardware raid (caro).
Si, como casi siempre: lo más caro suele ser más eficiente. Aunque no es ley inequívoca, claro.
;)
Jerry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-09 a las 17:27 +0100, Jordi Espasa Clofent escribió:
1- En disco1 el particionador de YaST _me obliga_ a definir, como mínimo, una partición /swap y otra /boot. El resto de disco es el que pongo como "partición sin formatear y tipo 0xFD Linux RAID.
Evidentemente, después creo el RAID tipo 1 en ambos discos. Pero claro... el disco2 es copia (en este caso) de la tercera particion del disco 1. O sea que estoy haciendo espejo de todo el árbol exceptuando /swap y /boot, que el sistema me ha obligado ha particionar de manera "clásica".
¿Significa esto que disco2 no tiene /swap y /boot? Porqué si así es no entiendo demasiado bien cómo será funcional el disco2 en caso de que disco1 se joda.
Lo normal sería poner en el disco 2 también otro /boot y otro /swap. Y otra alternativa que te cuento luego.
2- Si monto un sistema que necesite, por ejemplo, 5-6 particiones (/swap, /boot/, /home, /srv, /var, /tmp) ¿como haría entonces el tema del RAID 1 si, precisamente, el sistema me obliga a la opción No formatear+ Linux RAID para poder crear el espejo?
La verdad es que no lo entiendo.
Voy allá. Más adelante (salto un poco) dices:
El disco /dev/md0 no contiene un tabla de particines válida.
Bien. Hay dos maneras de hacer esto: una es hacer varias particiones raid: md0, md1, md2... que se formatean cada una con el sistema que quieras (arriba te faltó particionarla). Es posible, pero creo que poco util para ti. Y hay otra, que es ¡particionar el propio dispositivo /dev/md0! Por eso te sale ese mensajito de que no contiene particiones válidas: lo puedes usar tanto directamente, formateándolo, como lo puedes particionar con tantas particiones como desees - y es esto lo que estoy seguro que te está proponiendo el yast, pero no te das cuenta - y luego formtear cada una de ellas. Es una sospecha. Es decir, tendrías (por ejemplo) hda1 --> boot hda2 --> swap hda3 --> md0 --> y particionar una vez activada. Además, una de esas particiones dentro de md0 puede ser una swap. Es decir, tienes tres opciones para la swap: una swap de uno de los dos discos (y si falla se elige la otra en el arranque), repartirla entre dos los dos discos, en sus propias particiones, y ganando en velocidad de swap si tienen la misma prioridad, o ponerla en swap, con lo cual es un poco más lenta (más pasos de software, y escribir en dos discos), pero mucho más fiable.
3- Suponiendo además que los dos anteriores puntos se solucionan, todavía veo un inconveniente. Al estar el RAID montado en discos IDE, si el primario peta tengo un problema Houston, pues evidentemente en el montaje físico de los discos he puesto los jumpers para que definan cuál es el primario y cuál el secundario.
Es decir, si el primario peta, por mucho que el secundario esté preparado para substituirlo, la máquina volverá a buscar el primario para arrancar.
O no. Muchas bios permiten seleccionar que disco quieres que arranque. Además, si peta malamente, es posible que debas desenchufar el malo para poder arrancar. De todos modos, obtendrás mayor velocidad si pones cada disco en un cable distinto. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD7USutTMYHG2NR9URApIoAJ9212qroGtq6M1P7uIEG0ODY5/eDACeIkkJ exxHHXSTBHuIwCJOM9BylDE= =DibF -----END PGP SIGNATURE-----
El 10/02/06, Carlos E. R.
Además, una de esas particiones dentro de md0 puede ser una swap. Es decir, tienes tres opciones para la swap: una swap de uno de los dos discos (y si falla se elige la otra en el arranque), repartirla entre dos los dos discos, en sus propias particiones, y ganando en velocidad de swap si tienen la misma prioridad, o ponerla en swap, con lo cual es un poco más lenta (más pasos de software, y escribir en dos discos), pero mucho más fiable.
mmmm... no me suena para nada interessante realizar un raid de las particiones swap !!! acredito que la mejor alternatica es crear una particion swap independente en cada disco y en el SO utilizarlas como una so.. por ejemplo: se crear en cada disco una particion swap de 512 y configura el fstab para habilitar las dos, teniendo asi, una swap total de 1024MB. Logicamente, todo se cambia se vamos a hablar de discos hotswap y/o raid 5 (o otro semejante) [...]
Es decir, si el primario peta, por mucho que el secundario esté preparado para substituirlo, la máquina volverá a buscar el primario para arrancar.
O no. Muchas bios permiten seleccionar que disco quieres que arranque. Además, si peta malamente, es posible que debas desenchufar el malo para poder arrancar.
mmm.. crees que funcionaras transparentemente ??? digo por el grub/lilo que iran a buscar el boot en /dev/hda1 (por ejemplo) y esto disco fue justo lo que murio !!!! mmmm.. la verdad, no saberia decir si con grub existe posibilidad de especificar "nombres" a las particiones (http://www.europe.redhat.com/documentation/rhl7.3/rhl-rg-es-7.3/s1-filesyste...) como en el caso del fstab, tendria que buscar en el manual, pero ahora no tengo tiempo... pero se fuera asi, talvez funcionara de manera transparente !!!
De todos modos, obtendrás mayor velocidad si pones cada disco en un cable distinto.
esto indiscutiblimente !!!!
Saludos
salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-11 a las 01:03 -0300, Victor Hugo dos Santos escribió:
[...]
Además, una de esas particiones dentro de md0 puede ser una swap. Es decir, tienes tres opciones para la swap: una swap de uno de los dos discos (y si falla se elige la otra en el arranque), repartirla entre dos los dos discos, en sus propias particiones, y ganando en velocidad de swap si tienen la misma prioridad, o ponerla en swap, con lo cual es un poco más lenta (más pasos de software, y escribir en dos discos), pero mucho más fiable.
mmmm... no me suena para nada interessante realizar un raid de las particiones swap !!!
Si, si es posible. Yo no lo he hecho, pero se que es posible y se hace, lo han comentado en la lista. Supone más seguridad, porque si tienes la swap partida en dos discos y uno falla, el sistema se cae irremediablemente (si usa swap). En cambio, si la swap está en raid, resiste, aunque en modo degradado - siempre y cuando lo que falle del disco no sea la interfase ide y la queme.
acredito que la mejor alternatica es crear una particion swap independente en cada disco y en el SO utilizarlas como una so.. por ejemplo:
Si, eso es muy eficiente: más tamaño y si se definen con la misma prioridad, más velocidad. Yo lo he usado así mucho tiempo, pero he tenido que dejar de hacerlo porque entonces no puedo suspender a disco :-(
O no. Muchas bios permiten seleccionar que disco quieres que arranque. Además, si peta malamente, es posible que debas desenchufar el malo para poder arrancar.
mmm.. crees que funcionaras transparentemente ???
Hasta cierto punto.
digo por el grub/lilo que iran a buscar el boot en /dev/hda1 (por ejemplo) y esto disco fue justo lo que murio !!!! mmmm.. la verdad, no saberia decir si con grub existe posibilidad de especificar "nombres" a las particiones
Claro, los dos /boot de ambos discos deben ser casi gemelos, pero con alguna diferencia, precisamente en la referencia a la partición "boot" que usen. Por eso tampoco es mala idea dejar otra partición más, independiente del raid, con el tamaño suficiente para tener otro linux pequeño usable como partición de rescate - y duplicado en ambos discos.
(http://www.europe.redhat.com/documentation/rhl7.3/rhl-rg-es-7.3/s1-filesyste...) como en el caso del fstab, tendria que buscar en el manual, pero ahora no tengo tiempo... pero se fuera asi, talvez funcionara de manera transparente !!!
Si, poder poner etiquetas en el grub estaría muy bien. Aún y todo, habría que diferenciar ambos boot, pero permitiría cambiar un disco por el otro sin editar nada. Otro sitio donde interesan las etiquetas en la swap.
De todos modos, obtendrás mayor velocidad si pones cada disco en un cable distinto.
esto indiscutiblimente !!!!
¡Pues no lo creas! A mi me ha pasado, que si pongo cada disco en un cable, los discos comparten cable con las cederas y grabadoras - y estas no siempre soportan la alta velocidad del bus y lo fuerzan a ir más lento. Hay que probarlo :-( Lo mismo que la tipica discusión de si es mejor poner la swap en la primera partición, en el medio, o al final, y todo el mundo dando explicaciones que si la mayor velocidad lineal, etc. ¡Pos tampoco! Hay que medirla. Yo particioné mi disco en unas veinte particiones, y medí la velocidad: resultó ser bastante más rápido hacia el 30% de su superficie. Metodo científico ese, demostración por experimentación ;-) - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD7d28tTMYHG2NR9URAlqSAJ9t5IzbpgJa7Qx2cL45mxakB8Va9QCeIns3 Cp2BPkmq02rMhZI29FIr+DM= =Xx0c -----END PGP SIGNATURE-----
El 11/02/06, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE-----
[...]
De todos modos, obtendrás mayor velocidad si pones cada disco en un cable distinto.
esto indiscutiblimente !!!!
¡Pues no lo creas! A mi me ha pasado, que si pongo cada disco en un cable, los discos comparten cable con las cederas y grabadoras - y estas no siempre soportan la alta velocidad del bus y lo fuerzan a ir más lento.
mmm.. me referia a la "hipotesi" de que solamente fueran discos y nada mas !!! ;-)
Hay que probarlo :-(
Lo mismo que la tipica discusión de si es mejor poner la swap en la primera partición, en el medio, o al final, y todo el mundo dando explicaciones que si la mayor velocidad lineal, etc. ¡Pos tampoco! Hay que medirla.
Yo particioné mi disco en unas veinte particiones, y medí la velocidad: resultó ser bastante más rápido hacia el 30% de su superficie.
mmm.. si, me recuerdo de vuestros comentarios sobre el tema y ahora me viene a la cabeza de que esto podria ser un tema para un proyecto ... imaginate, un script que automaticamente particionara el disco en 20/40/50 particiones, medirá las velocidades de cada particion, mostrara el resultado y ademas pudiera ofrecer un esquema para el mejor particionamiento dependiendo de lo que vas hacer con la maquina (servidor de correo/archivos/news, etc) ??? Me pregunto el porque aun no habran echo algo semejante, ya que hoy en dia las distribuiciones hacen el posible para que funcione el mas rapido posible (principalmente el arranque del sistema). Y se observas los assistentes de particionamiento que vienen en instalacion, simplesmente te creas particiones predeterminadas, pero no miden la performance de los dispositivos (discos) !!!
Metodo científico ese, demostración por experimentación ;-)
hehehe salu2 -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-13 a las 16:05 -0300, Victor Hugo dos Santos escribió:
Yo particioné mi disco en unas veinte particiones, y medí la velocidad: resultó ser bastante más rápido hacia el 30% de su superficie.
mmm.. si, me recuerdo de vuestros comentarios sobre el tema y ahora me viene a la cabeza de que esto podria ser un tema para un proyecto ... imaginate, un script que automaticamente particionara el disco en 20/40/50 particiones, medirá las velocidades de cada particion, mostrara el resultado y ademas pudiera ofrecer un esquema para el mejor particionamiento dependiendo de lo que vas hacer con la maquina (servidor de correo/archivos/news, etc) ???
Hay una manera más fácil de hacerlo con los recursos que tiene una distribución: ajustar el comando hdparm, que es el que usamos para medir la velocidad, para que efectúe sus pruebas en una o varias zonas del disco que se le den en la linea de comandos. No haría falta particionar. Es decir, basta con añadir esa capacidad al programa de pruebas. O, si sus desarrolladores no quieren, buscar u hacer otro programa que sólo haga eso, medir la velocidad del disco en varias zonas.
Me pregunto el porque aun no habran echo algo semejante, ya que hoy en dia las distribuiciones hacen el posible para que funcione el mas rapido posible (principalmente el arranque del sistema). Y se observas los assistentes de particionamiento que vienen en instalacion, simplesmente te creas particiones predeterminadas, pero no miden la performance de los dispositivos (discos) !!!
Porque no todo el mundo busca afinar el sistema hasta tal punto, es una utilidad menor. Si realmente buscas velocidad, compras un disco rápido con una buena memoria tampón. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD8Pv7tTMYHG2NR9URAtbDAJ9yKWbE/jixQhwmNYmifXijxUbavQCglvp0 5dbgYnql9vhklEvNgOwP+w0= =RPwQ -----END PGP SIGNATURE-----
Hola :) El Lunes, 13 de Febrero de 2006 22:36, Carlos E. R. escribió:
El 2006-02-13 a las 16:05 -0300, Victor Hugo dos Santos escribi�:
Yo particion� mi disco en unas veinte particiones, y med� la velocidad: result� ser bastante m�s r�pido hacia el 30% de su superficie.
mmm.. si, me recuerdo de vuestros comentarios sobre el tema y ahora me viene a la cabeza de que esto podria ser un tema para un proyecto ... imaginate, un script que automaticamente particionara el disco en 20/40/50 particiones, medir� las velocidades de cada particion, mostrara el resultado y ademas pudiera ofrecer un esquema para el mejor particionamiento dependiendo de lo que vas hacer con la maquina (servidor de correo/archivos/news, etc) ???
Hay una manera m�s f�cil de hacerlo con los recursos que tiene una distribuci�n: ajustar el comando hdparm, que es el que usamos para medir la velocidad, para que efect�e sus pruebas en una o varias zonas del disco que se le den en la linea de comandos. No har�a falta particionar.
Es decir, basta con a�adir esa capacidad al programa de pruebas. O, si sus desarrolladores no quieren, buscar u hacer otro programa que s�lo haga eso, medir la velocidad del disco en varias zonas.
En el caso de los benchmarks, también es interesante las opciones con las que creas el sistema de ficheros (logs o journal, tamaño de bloque, si los atributos extendidos van juntamente con el inodo, si los datos van con el inodo, ...). También es interesante el número y tipo de RAID que vas a montar. En algunos benchmarks hemos visto que el mejor rendimiento se ve en LUNs de 6 discos, por ejemplo, para RAID 5.
Me pregunto el porque aun no habran echo algo semejante, ya que hoy en dia las distribuiciones hacen el posible para que funcione el mas rapido posible (principalmente el arranque del sistema). Y se observas los assistentes de particionamiento que vienen en instalacion, simplesmente te creas particiones predeterminadas, pero no miden la performance de los dispositivos (discos) !!!
Porque no todo el mundo busca afinar el sistema hasta tal punto, es una utilidad menor. Si realmente buscas velocidad, compras un disco r�pido con una buena memoria tamp�n.
Yo creo que es porque es muy complejo y la gran mayoría, como dice Carlos, se conforma con comprar un disco más rápido. Algunos clientes sí que ahcen estos benchmarks y buscan el óptimo. Rafa -- Rafa Grimán Systems Engineer Silicon Graphics Spain Santa Engracia, 120 - Planta Baja 28003 Madrid Spain Tel: +34 91 3984200 Tel: +34 91 3984201 Móvil: +34 628 117 940 http://www.sgi.com OpenWengo: rgriman Skype: rgriman
El 13/02/06, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE-----
[...]
Hay una manera más fácil de hacerlo con los recursos que tiene una distribución: ajustar el comando hdparm, que es el que usamos para medir la velocidad, para que efectúe sus pruebas en una o varias zonas del disco que se le den en la linea de comandos. No haría falta particionar.
oiga, ahora me sobro algo de tiempo y estuve buscando sobre esto de utilizar el hdparm sobre una determinada area del disco (conozco solamente la posibilidad de utilizarlo sobre un dispositivo, por ejemplo /dev/hda1 o /dev/hda ) y la verdad es que no encontre nada a respecto !!!! te refieres ah algun parametro del hdparm o algun "tip" en especial ??? en cualquer casos, cual seria ??? muchas gracias. salu2. -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-15 a las 14:30 -0300, Victor Hugo dos Santos escribió:
Hay una manera más fácil de hacerlo con los recursos que tiene una distribución: ajustar el comando hdparm, que es el que usamos para medir la velocidad, para que efectúe sus pruebas en una o varias zonas del disco que se le den en la linea de comandos. No haría falta particionar.
oiga, ahora me sobro algo de tiempo y estuve buscando sobre esto de utilizar el hdparm sobre una determinada area del disco (conozco solamente la posibilidad de utilizarlo sobre un dispositivo, por ejemplo /dev/hda1 o /dev/hda ) y la verdad es que no encontre nada a respecto !!!!
¡Claro que no existe! Lo que digo es que una distribución tiene recursos suficientes para hacerlo (o sea, añadirlo al programa), influir en los desarrolladores para que lo hagan, o hacer otro programa que lo haga. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD84wCtTMYHG2NR9URAl9DAJ91ZfvXdNTxCeJ3kqou99Ssn401qACeOZx/ Ppul6WvWa1DMfIm/KtXp2tM= =h4pK -----END PGP SIGNATURE-----
participants (6)
-
Carlos E. R. -
Jerry Westrick -
Jordi Espasa Clofent -
Miguel A. Casado -
Rafa Grimán -
Victor Hugo dos Santos