Hola Perdón ya que no lo puse correctamente, me refiero a que un disco duro normal alcanza velocidades de 70 u 80 KB/s en escritura, Suponiendo una conexión de 1Gb que son Aproximadamente 100 MB/s, los discos actuales (casi todos) no la soportan, PERO ME ENCANTARIA TENER UNA CONEXIÓN ASI. Un saludo. El Sunday 28 September 2008 20:39:44 Carlos E. R. escribió:

El 2008-09-28 a las 17:56 +0200, pedro Marquina escribió:

...

la había leído y se comenta en diferentes foros, pero esa velocidad (que es estupenda) no está soportada por la mayoría de los discos duros, que suele ser de 70 u 80 KB.

¡Que dices! Un disco duro soporta transferencias de varios megas. Incluso centenares de megas.

Mi pobre disco antiguo (del 2000) aguanta 26 megas por segundo, acabo de medirlo. Y eso son 260 megbits por segundo en habla de transmisión.

-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-28 a las 20:51 +0200, pedro Marquina escribió:

Cuando pongo 70 u 80 KB/s quiero decir 70 u 80 MB/s

Ah, vale. Fíjate que eso ya está cerca del giga en transmisión. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjf1/MACgkQtTMYHG2NR9W0UwCfZrUTEmZZKjGO6yuhTeonuTi1 1KQAn2rjePLeckG0aSTg8l8Vrz3t1Ks2 =15X8 -----END PGP SIGNATURE-----

Carlos E. R. escribió:

Además, esas velocidades pueden ser para varios usuarios en casa viendo peliculas. Un gigabit es lo que da una tarjeta de red moderna.

No solamente eso, si no que ademas, los datos van a memoria primero...la cual es __mucho__ mas rapida. -- "A computer is like an Old Testament god, with a lot of rules and no mercy. " Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/

El 28/09/08, pedro Marquina escribió:

la había leído y se comenta en diferentes foros, pero esa velocidad (que es estupenda) no está soportada por la mayoría de los discos duros, que suele ser de 70 u 80 KB.

Ya veo que querías decir MB. Pero ojo que el sata 300 tiene una tasa de transferencia de hasta 300 MB/s y la nueva especificación sube hasta los 6 Gb/s (si no vuelvo a meter la pata con las unidades...). <modo futurista on> Aún así... ¡¡ el disco duro es el pasado!! :-P Dentro de poco, desde nuestros terminales tontos sin unidad de almacenamiento pero con conexiones múltiples de fibra óptica podremos elegir a qué servidor nos queremos conectar (servidor en California, en Lausanne o en Sydney) para iniciar una sesión remota y acceder a nuestros datos que estarán además replicados entre los distintos mega-servidores redundantes... ;-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 28/09/08, Carlos E. R. escribió:

Siguiendo en modo futurista, yo me pongo en modo 1984 y recuerdo lo de gran hermano... no, mis datos en casita y encriptados.

¡¡ Grrr !! Eres un experto en desmontar mis planes perversos de dominación mundial... ¡dita sea! >:-) (¬_¬ pensando... Ya sé dónde enviar mi ejército de caracoles controlados vía wifi en primer lugar..) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El Sunday 28 September 2008 22:01:36 Camaleón escribió:

(...)

<modo futurista on>

Aún así... ¡¡ el disco duro es el pasado!! :-P

Dentro de poco, desde nuestros terminales tontos sin unidad de almacenamiento pero con conexiones múltiples de fibra óptica podremos elegir a qué servidor nos queremos conectar (servidor en California, en Lausanne o en Sydney) para iniciar una sesión remota y acceder a nuestros datos que estarán además replicados entre los distintos mega-servidores redundantes...

<modo mundo-real on> En los próximos veinte años telefónica participará de los principales nodos de comunicaciones del mundo y habrá comprado las redes de varios países. Para entonces ofrecerán su superpaquete en superoferta "ADSL TRÍO + imagenio" con 101 MB. Claro que sólo los abonados a esa compañía que vivan a 10 minutos de las oficinas de telefónica de algunas ciudades podrán disfrutar de ese servicio. Pero esos afortunados usuarios se encontrarán de que, aunque los supermegarrápidos superservidores a los que se conectan usan tecnología abierta y libre, los encaminadores del operador telefónico de turno están usan tecnología Microsoft Windows Server(R) 2027... <modo mundo-real off> Salud!! -- ------------- karl -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola. Recuerdo hace años, cuando los bancos utilizaban terminales tontos, con pantalla de fósforo verde. Si en España tenemos que esperar a una conexión de Fibra óptica a precio asequible, Te recomiendo que empieces a ahorrar para comprar discos duros. :)) Al paso que vamos con un poco de suerte, en el próximo siglo cuando ya hubiese algo que sustituya a los ordenadores, en España te venderán la Fibra óptica como de ultima generación y pagando una brutalidad. Eso sí, con el apoyo de la CMT. Lo que indico no es que no exista fibra óptica en España, es que le sale mas rentable seguir teniéndola enterrada. Yo hace unos 12 - 15 años en ciudad real tenía RDSI Un saludo.

<modo futurista on>

Aún así... ¡¡ el disco duro es el pasado!! :-P

Dentro de poco, desde nuestros terminales tontos sin unidad de almacenamiento pero con conexiones múltiples de fibra óptica podremos elegir a qué servidor nos queremos conectar (servidor en California, en Lausanne o en Sydney) para iniciar una sesión remota y acceder a nuestros datos que estarán además replicados entre los distintos mega-servidores redundantes...

;-)

Saludos,

-- Camaleón

-- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 29/09/08, Rafa Grimán escribió:

Bueno, los 300 MB/s son tasa teórica en sólo lectura o sólo escritura. El día que yo vea un único disco escribiendo o leyendo a esa velocidad ... creeré todo lo que haga falta ;)

Ya veo... así que tú también quieres que te envíe mi ejército de súper-caracoles modificados genéticamente y controlados vía wifi ¿eh?

:-)

Je, pues a ti te tengo más cerca...

Teniendo en cuenta que los disco duros tienen que soportar lectura _Y_ escritura al mismo tiempo, y que eso es lo que más daña el rendimiento ... podemos irnos sentando y esperando un rato largo hasta que tengamos rendimientos superiores a 50 MB/s (en RAID 5 es menor a los 50 MB/s por disco del RAID).

Tampoco será ese giga "un giga" como tal. Teniendo en cuenta que es "hasta" y las distancias, etc... no creo que haya problema con discos duros y buses actuales. Lo importante de este historia (o vaya, al menos lo que yo considero más importante) es lo siguiente: - Sin competencia real en el mercado nos estancamos y los clientes pierden :-( - Que la velocidad no es lo más importante sino la infraestructura que tiene el proveedor y si me dice que puede ofrecer estos "hasta 1 giga" a mi me da a entender que tiene una buena base.

Sí, las cachés ayudan, pero ... lo que está en caché se puede perder y eso no es gracioso.

A esto hay que sumar: - el disco va creciendo, pero la velocidad de rotación no :( - los sistemas de ficheros tienen que mejorar el rendimiento - los buses tienen que mejorar mucho

No hay que olvidar que el ancho de banda de ese giga se reparte entre televisión HD, teléfonos, internet, móviles, etc... es decir, que ese giga ya se me está quedando corto :-P

Y no, los SSD no los tengo a la vista porque tienen una vida media baja :(

Bueno, después de esta demostración de optimismo, debo aconsejaros empezar a mirar hacia SAS: mejor rendimiento y precios "buenos". Dan un rendimiento muy cercano a FC y son mucho más baratos, pero muchísimo más baratos.

Resérvame uno de esos... allá para el 2.030 con pago a cómodos plazos y garantía de por vida :-P

Si algún día vemos en España algo cercano al Gbps en Internet ... ya habrá discos de estado sólido con vida media de cien años x"D

Eso es total y absolutamente cierto :-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 29/09/08, Rafa Grimán escribió:

Menos mal que estás tu porque no había caído en esto 0:) Vamos que nos vale con un floppy ;)

Grrr. Está bien, está bien... voy a llamar a Telefónica (ring, ring) para que os baje el ancho de banda de 3/6 megas a 1... total, si no os hace falta ¿no? >:-)

No hombre, no. No son tan caros, los de FC sí son caros, los SAS son más baratos. A lo mejor como para tener 2 TB en casa no (actualmente son de hasta 400 GB), pero sí son más baratos.

Yo, personalmente, creo que no llego a los 300 GB de morralla en mis discos ... la verdad es que si me pongo a hacer limpieza seguro que se queda en unos 200 GB. Así que no veo SAS como mala opción para mi.

La pega que le veo a los sas es la "compatibilidad". Es decir, con los discos magneto ópticos me pasó lo mismo: eran una buena alternativa pero nadie tenía unidades lectoras y no podía llevarlos a ningún lado por lo que sólo los usábamos a modo de copia de seguridad :-(. Y ahora tengo problemas con los scsi... ¿"ande" los pincho? :-? Necesito cajas externas scsi-usb para conectarlos porque la mayoría de equipos que tenían adaptadores scsi (integrados en la placa o con tarjeta) están pasando a la reserva por tener más de 5 años... Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 29/09/08, Carlos E. R. escribió:

El 2008-09-29 a las 15:22 +0200, Camaleón escribió:

...

Y ahora tengo problemas con los scsi... ¿"ande" los pincho? :-? Necesito cajas externas scsi-usb para conectarlos porque la mayoría de equipos que tenían adaptadores scsi (integrados en la placa o con tarjeta) están pasando a la reserva por tener más de 5 años...

¿No los siguen vendiendo, o es que ya no los comprais?

Hombre, claro que los venden... pero nos hemos pasado a la "patata", estooo, quiero decir, al S-ATA O:-), precisamente para "compatibilizar". ¿Motivo? Pues no tengo ninguna queja de los scsi (han servido bueno y bien) pero siguen teniendo unas capacidades muy bajas. Quería poner un raid 5 y tiré por sata porque conseguir 1,2 TB en scsi, te sube mucho el presupuesto y los discos sas no son tan fáciles de encontrar :-/ Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) El Monday 29 September 2008, Camaleón escribió:

El 29/09/08, Carlos E. R. escribi�:

...

El 2008-09-29 a las 15:22 +0200, Camale�n escribi�:

...

Y ahora tengo problemas con los scsi... �"ande" los pincho? :-? Necesito cajas externas scsi-usb para conectarlos porque la mayor�a de equipos que ten�an adaptadores scsi (integrados en la placa o con tarjeta) est�n pasando a la reserva por tener m�s de 5 a�os...

�No los siguen vendiendo, o es que ya no los comprais?

Hombre, claro que los venden... pero nos hemos pasado a la "patata", estooo, quiero decir, al S-ATA O:-), precisamente para "compatibilizar".

SAS permite conectar SATA y SAS :)

�Motivo? Pues no tengo ninguna queja de los scsi (han servido bueno y bien) pero siguen teniendo unas capacidades muy bajas. Quer�a poner un raid 5 y tir� por sata porque conseguir 1,2 TB en scsi, te sube mucho el presupuesto

Pues si vas a montar un almacenamiento con SATA que requiere cierta seguridad, vete pensando en: - RAID 6 (p+q) _Y_ - tener unos cuantos spare A los SATA, cuando les das mucha caña fallan que da gusto, especialmente si son más grandes de 500 GB. No quiero meter miedo a nadie, sólo quiero que sepan a lo que atenerse. Cuando vendemos sistemas de almacenamiento con SATA, se lo dejamos muy claro al cliente ... claro que la decisión es suya, pero que sepa que se lo hemos advertido. Ojo, hablo de entorno servidor, no hablo de entorno casero. Reventar un SATA en entorno casero (en el que se hace un uso casi nulo del disco duro) es signo de que falla otra cosa: fuente de alimentación, cable, placa base, driver, controladora, ... En cambio, en los servidores de ficheros, se castiga mucho al disco duro: hay muchos usuarios haciendo mucha lectura y mucha escritura. Almacenamiento SATA está bien para los tier 2 (near line) y 3 (off line) en sistemas de HSM o bien para archivado o backup a disco ya que no tienen un elevado acceso a disco. Pero si hablas de Tier 1 (on line), mejor ir a por SAS.

y los discos sas no son tan f�ciles de encontrar :-/

Tengo yo unos discos SAS más majos ... ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) El Tuesday 30 September 2008, Camaleón escribió:

El 30/09/08, Rafa Grim�n escribi�:

...

SAS permite conectar SATA y SAS :)

Venga, para el pr�ximo servidor lo tendr� en cuenta :-)

Ahí estamos, con ganas de innovar :)

...

Pues si vas a montar un almacenamiento con SATA que requiere cierta seguridad, vete pensando en: - RAID 6 (p+q) _Y_ - tener unos cuantos spare

La controladora s�lo permite raid 0, 1, 10, 5 y jbod y prefer�a hardware raid. Aunque ahora me replantear�a usar raid :-/

Pues prepara los spare.

...

A los SATA, cuando les das mucha ca�a fallan que da gusto, especialmente si son m�s grandes de 500 GB.

400 gb. cada disco. Pero �por qu� dices que fallan? �Y qu� es lo que falla? :-?

El problema es que son mecánicos. Hay mucho volumen (750 GB, 1 TB) y los cabezales tienen que bascular mucho por lo que la mecánica acaba fallando si hay mucho I/O. Hasta 500 GB, la tecnología funciona bien, pero de ahí en adelante ... se corre mucho riesgo. Al fallar la mecánica ... hay que reemplazar el disco entero, no es cosa de reformatear o driver nuevo o cosas así :( Hay otro inconveniente de discos grandes (mayores a 500 GB) y es el tiempo de reconstrucción. Si tienes un RAID 5 y te falla un disco y entra el spare (o bien lo cambias por uno nuevo), el tiempo de reconstrucción es ETERNO. He llegado a ver una reconstrucción de un RAID 5 con discos de 1 TB tardar 28 horas !!! Eso trae consigo dos problemas: - mientras se reconstruye, (recuerda que son 28 horas), te puede fallar otro disco y si es RAID 5 ... pierdes el RAID entero - mientras se reconstruye, el rendimiento del RAID te cae y puedes llegar a ver un rendimiento del 40% respecto del original [...]

...

Almacenamiento SATA est� bien para los tier 2 (near line) y 3 (off line) en sistemas de HSM o bien para archivado o backup a disco ya que no tienen un elevado acceso a disco. Pero si hablas de Tier 1 (on line), mejor ir a por SAS.

Lo utilizamos de almacenamiento masivo puro y duro (backup, archivos gordos, etc...).

Teniendo en cuenta que son de 400 GB y que el uso que le das es más de archivado y backup, te durarán más, pero ten alguno de spare a mano. Consejos para que duren más o para que tengas menor probabilidad de perder datos: - RAID 6 - haz RAIDs pequeños (4+1 si es RAID 5 y 4+1+1 si es RAID6) Lo del RAID 6, que sea p+q porque es el estándar, el DP no es estándar (cada fabricante hace lo que le da la gana).

...

Tengo yo unos discos SAS m�s majos ... ;)

Haylos :-), pero no se encuentran tan f�cilmente como los s-ata.

Yo tengo muchos aquí en el almacén ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) El Tuesday 30 September 2008, Camaleón escribió:

El 30/09/08, Rafa Grimán escribió:

...

El problema es que son mecánicos. Hay mucho volumen (750 GB, 1 TB) y los cabezales tienen que bascular mucho por lo que la mecánica acaba fallando si hay mucho I/O. Hasta 500 GB, la tecnología funciona bien, pero de ahí en adelante ... se corre mucho riesgo.

Al fallar la mecánica ... hay que reemplazar el disco entero, no es cosa de reformatear o driver nuevo o cosas así :(

Pero los fallos no son exclusivos del sata (ni del disco ni de la interfaz) en particular. Los discos con conexión scsi (o sas o FC) de gran capacidad adolecen del mismo mal ¿no?

Lo comentábamos hace poco, que la calidad del disco duro depende del fabricante, de las especificaciones del propio disco y del segmento al que va dirigido, pero no tanto del tipo de interfaz... :-?

Sí, eso también hay que tenerlo en cuenta. En el caso de SATA grande (>500GB). Es demasiado grande para el rotor/motor. Le cuesta mucho balancear los cabezales de un lado a otro del disco. En cuanto a discos SCSI/SAS y FC. Se prueban mucho, son discos mucho más pequeños, ...

...

Hay otro inconveniente de discos grandes (mayores a 500 GB) y es el tiempo de reconstrucción.

No me lo recuerdes... 6 / 7 horas que se lleva para reconstruir el tera (y ademaś, son falsos positivos).

Vaya :(

...

Si tienes un RAID 5 y te falla un disco y entra el spare (o bien lo cambias por uno nuevo), el tiempo de reconstrucción es ETERNO. He llegado a ver una reconstrucción de un RAID 5 con discos de 1 TB tardar 28 horas !!!

Lo es, lo es... y eso es lo que me hace replantearme el uso del raid: tienes que afinar mucho con la controladora y con las herramientas que vas a utilizar. Hay drivers del kernel para detectar la controladora pero no tengo herramientas del kernel para gestionar el raid y tengo que usar las del fabricante que requiere usar "su" controlador :-/

Eso es lo malo del RAID por hw. En cuanto a disco de spare, a mi no me gustan, prefiero un disco de reemplazo definitivo. Si usas un spare, hay que reconstruir el RAID 2 veces: - 1 cuando falla el disco y entra el spare - la segunda cuando cambias el disco dañado por uno nuevo: hay que copiar todo lo que tenía el spare al disco nuevo

...

Eso trae consigo dos problemas:

- mientras se reconstruye, (recuerda que son 28 horas), te puede fallar otro disco y si es RAID 5 ... pierdes el RAID entero

Je, estaría bueno... poner un raid para evitar perder datos por fallo del disco... ¡y perderlos por el raid! >:-)

Recuerda que RAID 5 sólo previene ante fallos de 1 disco. Si fallan dos discos ... has perdido tus datos. Para eso sacaron RAID 6, es como un RAID 5, pero con doble paridad.

...

- mientras se reconstruye, el rendimiento del RAID te cae y puedes llegar a ver un rendimiento del 40% respecto del original

En mi caso tengo en el mismo servidor 2 niveles de raid (raid1 para el so y el raid5 sólo para almacén). Perdería datos, en caso de que fallen dos discos del raid5 o el acceso sería muy lento si está degradada, pero al menos el servidor seguiría en marcha.

No, no me haría gracia :-P.

Efectivamente, perder datos no hace gracia :( De ahí que luego te saquen cosas como disaster recovery y business continuance, backups, ...

...

Teniendo en cuenta que son de 400 GB y que el uso que le das es más de archivado y backup, te durarán más, pero ten alguno de spare a mano.

Por eso necesito que sea sencillo conseguir unos cuantos discos sata y con los sas, no sé, no sé... >:-)

...

Consejos para que duren más o para que tengas menor probabilidad de perder datos: - RAID 6

Con software raid, quizá... porque el 6 no es un nivel de raid muy común en las controladoras :-?

Empieza a serlo, pero recuerda, hay dos tipos de RAID 6: - RAID 6 p+q: es el definido en el estándar - RAID 6 DP: no está definido por ningún estándar y cada fabricante hace lo que le da la gana. En algunos casos da peor rendimiento

...

- haz RAIDs pequeños (4+1 si es RAID 5 y 4+1+1 si es RAID6)

Lo del RAID 6, que sea p+q porque es el estándar, el DP no es estándar (cada fabricante hace lo que le da la gana).

Oído cocina :-)

Se me olvidaba otra cosa a tener en cuenta: stripe width y stripe unit. Importantes para el rendimiento. Algunos sistemas de ficheros (como XFS) te permiten definir el stripe width y stripe unit para que sean el mismo número que tiene el RAID. Aunque en tu caso (backups) no creo que sea tan necesario ya que no buscas un rendimiento óptimo que te obligue a atarte a la silla ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) El Tuesday 30 September 2008, Carlos E. R. escribió:

El 2008-09-30 a las 12:31 +0200, Rafa Grimán escribió:

...

Eso es lo malo del RAID por hw.

En cuanto a disco de spare, a mi no me gustan, prefiero un disco de reemplazo definitivo. Si usas un spare, hay que reconstruir el RAID 2 veces: - 1 cuando falla el disco y entra el spare - la segunda cuando cambias el disco dañado por uno nuevo: hay que copiar todo lo que tenía el spare al disco nuevo

No tienes porqué. El nuevo pasa a ser el spare.

Depende de la configuración. En algunos entornos no te interesa que el spare sea parte del RAID porque pierdes rendimiento ya que se encuentra en la misma bandeja. Hay que tener cuidado con esas cosas ... Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) El Tuesday 30 September 2008, Carlos E. R. escribió:

El 2008-09-30 a las 13:24 +0200, Rafa Grimán escribió:

...

...

No tienes porqué. El nuevo pasa a ser el spare.

Depende de la configuración. En algunos entornos no te interesa que el spare sea parte del RAID porque pierdes rendimiento ya que se encuentra en la misma bandeja. Hay que tener cuidado con esas cosas ...

¿No se ponía cada disco en su propio bus? :-?

Sí, pero hay que tener en cuenta tres cosas: 1.- muchas empresas diseñan la electrónica interna de las cabinas como loops y no como switch. Es decir, para que el dato llegue al disco 3, tiene que pasar primero por el disco 1, luego por el 2 y acaba en el 3. En el caso de switch, va directamente al disco 3. 2.- al hacer un RAID, el hecho de tener que calcular la paridad y escribirla, hace que se pierda rendimiento en los discos. 3.- las bandejas de discos van conectadas mediante dos cables a las cabinas. Por lo que no se consigue realmente la suma de los anchos de banda de todos los discos. Debido a esto, si tienes una controladora con 8 conexiones a disco (como están redundadas, tendrías 16 puertos), podrías conectar directamente 8 bandejas para que cada una tuviera un cable a cada controladora. Si añades bandejas de discos, ya se empiezan a compartir buses (puertos de conexión). A lo que iba, tienes 8 bandejas, cada bandeja tiene 16 discos. Si haces un RAID 5 de 4+1 discos en la misma bandeja, usarás el ancho de banda de esa bandeja, pero si el RAID lo repartes entre las 8 bandejas (bueno, en realidad 5 bandejas porque tienes 5 discos), usarás el ancho de banda de las 5 bandejas. En el momento que falle un disco y el spare esté en la misma bandeja que otro de los discos del RAID ... no tendrás tan buen rendimiento ya que por un mismo cable pasan los dos discos :( Por no hablar de la distribución de los LUNs a cada controladora, el balanceo del gestor de volúmenes, la optimización del sistema de ficheros y el balanceo de los directorios para que se vayan colocando en diferentes volúmenes que deberían estar en diferentes LUNs conectados a diferentes controladoras ... pero eso lo dejamos para otro día ;) Rafa -- Rafa Grimán Systems Engineer Silicon Graphics, S.A. Sociedad Unipersonal Plaza del Descubridor Diego de Ordás 3 Tel: +34 91 398 42 00 Edificio Santa Engracia 120 Fax: +34 91 398 42 01 28003 Madrid Mobile: +34 628 11 79 40 Spain E-mail: rgriman@sgi.com http://www.sgi.com Skype: rgriman NIF - A79415873. Inscrita en el Registro Mercantil de Madrid Tomo 207, Folio 104, Hoja M-4186 el 5-7-90 __________________________________________________________________________ NB: INFORMATION IN THIS MESSAGE IS SGI CONFIDENTIAL. IT IS INTENDED SOLELY FOR THE PERSON(S) TO WHOM IT IS ADDRESSED AND MAY NOT BE COPIED, USED, DISCLOSED OR DISTRIBUTED TO OTHERS WITHOUT SGI CONSENT. IF YOU ARE NOT THE INTENDED RECIPIENT PLEASE WILL YOU NOTIFY ME BY EMAIL OR TELEPHONE, DELETE THE MESSAGE FROM YOUR SYSTEM IMMEDIATELY AND DESTROY ANY PRINTED COPIES. NB: LA INFORMACION CONTENIDA EN ESTE MENSAJE ES CONFIDENCIAL DE SGI. ESTA DIRIGIDA UNICAMENTE A LA PERSONA(S) A LA CUAL SE ENVIA Y NO PUEDE SER COPIADA, UTILIZADA, DIVULGADA O DISTRIBUIDA A OTROS SIN EL CONSENTIMIENTO PREVIO DE SGI. SI USTED NO ES EL DESTINATARIO INDICADO HAGA EL FAVOR DE NOTIFICARMELO POR MAIL O POR TELEFONO, BORRE EL MENSAJE DE SU SISTEMA INMEDIATAMENTE Y DESTRUYA CUALQUIER COPIA IMPRESA "We cannot treat computers as Humans. Computers need love." Happily using KDE 3.5.7 :) -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) El Wednesday 01 October 2008, Carlos E. R. escribió: [...]

...

A lo que iba, tienes 8 bandejas, cada bandeja tiene 16 discos. Si haces un RAID 5 de 4+1 discos en la misma bandeja, usarás el ancho de banda de esa bandeja, pero si el RAID lo repartes entre las 8 bandejas (bueno, en realidad 5 bandejas porque tienes 5 discos), usarás el ancho de banda de las 5 bandejas. En el momento que falle un disco y el spare esté en la misma bandeja que otro de los discos del RAID ... no tendrás tan buen rendimiento ya que por un mismo cable pasan los dos discos :(

¡Ahhhh! Es que las bandejas no son tontas. Yo pensaba que el cable iba directamente, con varios conectores si quieres, de la tarjeta contrladora al disco. Pero no, es que interviene la electronica de la bandeja, que multiplica la capacidad de cada cable como los panes. Todo tiene sus pegas...

¿Hablas de cables scsi? Con los sata no sabía que se pudiera hacer eso.

Son cables FC o SAS.

...

Por no hablar de la distribución de los LUNs a cada controladora, el balanceo del gestor de volúmenes, la optimización del sistema de ficheros y el balanceo de los directorios para que se vayan colocando en diferentes volúmenes que deberían estar en diferentes LUNs conectados a diferentes controladoras ... pero eso lo dejamos para otro día ;)

Uff. Mejor te llamo para que me lo pongas. Y que te pague el jefe. :-)

;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 30/09/08, Carlos E. R. escribió:

Tiene que ser simplemente porque los scsi son más pequeños, no porque sean más fiables. Escoge sATA pequeños y tendrás lo mismo.

Será eso. Pues ya han sacado unidades de 1 tera de capacidad...

No los pierdes por el raid. Has perdido dos discos duros, y de no tener raid estarías fuera de combate con el primero.

No los pierdo por el raid... directamente, pero en el proceso de reconstrucción se puede caer el otro disco. Ojo, que yo hablo de "caídas", no que el disco se "rompa" de verdad. La controladora puede tirar los discos por "x" motivo (conexión del cable floja, adaptador en mal estado, driver, etc...). Lo que me pregunto es cómo de reales son los datos de la controladora. ¿Un disco que lo marca como degradado está realmente "roto"? Pues no, vaya, en alguna ocasión me los ha tirado y ha vuelto a reconstruir el raid con el mismo disco. Pero ¿y si tira un segundo disco en plena reconstrucción del raid5? El disco no está roto pero lo saca del raid por lo que a afectos de la matriz no están accesibles esos datos, luego ¿perdería información...o no? :-? Por eso mi nivel de confianza con el raid no está del todo claro. Es decir, desde que he puesto el raid es cuando estoy empezando a temer por la pérdida de datos, cuando debería ser al revés (¿y si falla la controladora, y si falla el driver, y si falla un cable, y si...?). Respuesta: backup O:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) El Tuesday 30 September 2008, Camaleón escribió: [...]

Pero �y si tira un segundo disco en plena reconstrucci�n del raid5? El disco no est� roto pero lo saca del raid por lo que a afectos de la matriz no est�n accesibles esos datos, luego �perder�a informaci�n...o no? :-?

Sí.

Por eso mi nivel de confianza con el raid no est� del todo claro. Es decir, desde que he puesto el raid es cuando estoy empezando a temer por la p�rdida de datos, cuando deber�a ser al rev�s (�y si falla la controladora, y si falla el driver, y si falla un cable, y si...?).

Respuesta: backup O:-)

Pero ... te puede fallar la cinta o disco donde hagas backup. Por no hablar de la gente que hace backups, pero nunca comprueba si se puede restaurar o si los datos están realmente en la unidasd de backup. Te cuento un caso de un cliente que tenemos. Le montamos DMF (nuestro HSM) y le decimos: "Esto no es un sistema de backup, sería interesante que tuvieras un backup". El Tier 3 es una STK8500 (un "montruo"). Nos dice el cliente: "En 40 años trabajando en el mundo de la informática, nunca he visto una cinta estropeada". Dos días después, ¿qué se estropea? Pues no, no se estropeó una cinta, se estropeó el drive y ¿qué tenía dentro el drive? Sí, una cinta. Diréis: "Es que las cintas ...". Los discos duros igual, sobre todo los SATA y cuanto más grandes, más probabilidad de fallo. Por si eso no fuera poco, la gente quiere hacer RAID 5 de 30 (29+1) discos con discos SATA de 1 TB !!! Ande vas !!! Si los discos de 1 TB fallan que da gusto y encima montas un RAID 5 con 30 discos ... no te quiero contar la probabilidad que tienes de que te fallen 2 discos dentro de un mismo LUN. Sin tener en cuenta tiempos de reconstrucción de RAID. RAID está bien, backups están bien, DR está bien, BC está bien, ... Pero nada es infalible. El mismo cliente de antes me dice un día que quieren montar un DR y que qué haría falta, le respondí: "Pues lo mismo que tienes aquí, pero en tu oficina remota". Me respondió: "Es que no tenemos pasta". Como vió que no me conmovía mucho, me empezó a decir que la humedad de la zona afectaba al hardware que si la abuela fuma que si tengo tos ... hasta que me dice: "¿Y si nos cae un avión encima?". Ya reaccioné y le dije: "En ese caso: corre". Otro (futuro) cliente nos dijo que una vez les cayó un rayo y les fundió todo el hardware así que quería un DR en el mismo rack !!! No señor, un DR tiene que estar físicamente lejos el uno del otro. Pero bueno, Camaleón, no te preocupes que si tienes un SATA (o dos) en el cajón, estás relativamente protegida y puedes dormir tranquila ... pero piensa en un sistema de backup por si las moscas ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) El Tuesday 30 September 2008, Carlos E. R. escribió:

El 2008-09-30 a las 14:31 +0200, Rafa Grimán escribió:

...

...

Respuesta: backup O:-)

Pero ... te puede fallar la cinta o disco donde hagas backup. Por no hablar de la gente que hace backups, pero nunca comprueba si se puede restaurar o si los datos están realmente en la unidasd de backup.

Te cuento un caso de un cliente que tenemos. Le montamos DMF (nuestro HSM) y

Huy, esas abreviaturas... O:-)

Perdón, son la sprisas: - HSM Hierarchical Storage Management = ILM Information Lifecycle Management = DLM Data Lifecycle Management - DMF Data Migration Facility, es como llamamos a nuestro HSM Los HSM lo que hacen es que te permiten tener varios estratos o niveles (Tiers) de almacenamiento. Por ejemplo: - Tier 1: discos Fibre Channel poco espacio en disco (5 TB) es caro poco denso (discos de 300 GB) - Tier 2: discos SATA más espacio en disco (30 TB) es barato muy denso (discos de 1 TB) - Tier 3: cinta o discos ultra densos mucho espacio (100 TB) es más barato El software HSM lo que hace es que te permite establecer unas reglas que migren los datos de un Tier a otro automágicamente, sin que el usuario se dé cuenta. Las reglas pueden basarse en: tamaño de fichero, fecha, usuario, ... El usuario verá un único disco de 100TB+30TB+5TB =135 TB, cuando en realidad sólo puede usar 5 TB. Cuando hay un fichero en cinta y el usuario hace doble click sobre él, el HSM automáticamente migra el fichero de cinta a Tier 1. El usuario notará cierto retraso, pero no mucho ya que no es necesario que se migre el fichero entero para poder abrir el fichero, sino que a los pocos KB, el usuario ya empieza a ver datos en su pantalla.

...

le decimos: "Esto no es un sistema de backup, sería interesante que tuvieras un backup". El Tier 3 es una STK8500 (un "montruo"). Nos dice el cliente: "En 40 años trabajando en el mundo de la informática, nunca he visto una cinta estropeada". Dos días después, ¿qué se estropea? Pues no, no se estropeó una cinta, se estropeó el drive y ¿qué tenía dentro el drive? Sí, una cinta.

X'-)

Murphy.

...

Diréis: "Es que las cintas ...". Los discos duros igual, sobre todo los SATA y

Las cintas, una vez guardadas, son muy sólidas. Dentro de la caja ignífuga. En uso... es otro cantar.

Lo malo es que pase mucho tiempo y no tengas drives para leer esas cintas ;)

...

cuanto más grandes, más probabilidad de fallo. Por si eso no fuera poco, la gente quiere hacer RAID 5 de 30 (29+1) discos con discos SATA de 1 TB !!!

Ostras. Me parece que el de linux protesta en ese caso. Te los pone como spares salvo tres.

Eso no lo sabía, bueno saberlo :)

...

Ande vas !!! Si los discos de 1 TB fallan que da gusto y encima montas un RAID 5 con 30 discos ... no te quiero contar la probabilidad que tienes de que te fallen 2 discos dentro de un mismo LUN. Sin tener en cuenta tiempos de reconstrucción de RAID.

¿Se pondrían en varios niveles, no?

Hay cosas como RAID 6 (= que RAID 5, pero con 2 discos de Paridad), puedes usar copias de volúmenes, hacer RAIDs más pequeños, ... Pero claro, vas perdiendo espacio en disco ya que usas replicación, más discos de paridad, ... y todo eso consume espacio.

...

RAID está bien, backups están bien, DR está bien, BC está bien, ... Pero nada

Las abreviaturas :-)

Otra vez 0:) DR = Disaster Recovery BC = Business Continuance Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Los HSM lo que hacen es que te permiten tener varios estratos o niveles (Tiers) de almacenamiento. Por ejemplo: - Tier 1: discos Fibre Channel poco espacio en disco (5 TB) es caro poco denso (discos de 300 GB)

Donde estoy yo, los discos de 300GB son de calidad 'media', debido a que al ser tan grandes, el tiempo de acceso es mayor de lo que se necesita. Para discos rápidos usamos Fibre Channel/FC de 72GB a 15k rpm.

- Tier 3: cinta o discos ultra densos mucho espacio (100 TB) es más barato

... y más lento, claro. Son válidos en ciertas situaciones, como todo.

Otra vez 0:)

DR = Disaster Recovery

BC = Business Continuance

A esto lo llamo yo Business Continuity :-? Super - interesante lo que has contado. Gracias por compartirlo. -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Pero es que la situación que describe Rafa es una gozada. Tu usas un "algo" con unos discos muy rápidos. Si un archivo no se usa en bastante tiempo, ese trasto lo quita de los discos rapidos y lo pone en otros discos mayores y más lentos. Si sigue sin usarse en más tiempo lo traslada a la capa 3, más lenta y de mayor capacidad. Si de repente se usa, pues lo recupera en cuanto puede, tarda un poco más, y lo vuelve a poner en la primera capa.

Todo esto sin tener que mandar a un pringado a enchufar el backup.

je je... y esto se puede complicar hasta el infinito. Donde estoy en proyecto ahora estoy descubriendo estas cosas ahora. Por ejemplo. Los datos ya no se guardan backup, o no necesariamente, o no como única solución para cuando te encuentras problemas. Pensando en escenarios de Desastre, ahora se hacen copias de los datos. Estas copias pueden ser de dos tipos: Síncrona o Asíncrona. Las dos copias se gestionan a nivel de cabina de discos (los servidores ni se enteran, salvo que exista algun cuello de botella en la SAN o en la LAN). Las propias cabinas de discos replican datos entre ellas, y en caso de desastre, cortan los enlaces entre ellas y se posicionan como copia primaria (o secundaria, según el caso). En el caso de copia síncrona de datos, las cabinas replican _instantáneamente_ cualquier dato que se escriba en la copia primaria de discos. Hasta que el dato no se ha replicado en la cabina secundaria, el servidor no recibe el ok de que el dato se ha escrito. En el caso de la copia asíncrona, se establecen grupos de consistencia. Cada X tiempo, se sincronizan aquellos ficheros nuevos o que hayan cambiado. En este caso existe cierto retraso hasta que se envían los datos a la cabina con la copia asíncrona. En entornos grandes (muy grandes) existen los tres entornos: - copia primaria: cabinas en una SAN donde se escriben los datos desde los servidores. - copia secundaria: cabinas en una SAN en réplica síncrona con las cabinas primarias. - copia terciaria: cabinas en una SAN en réplica asíncrona con, o bien los datos primarios o bien los datos secundarios (estas dos configuraciones tienen pros y contras, según lo que persigas y la configuración que tengas te interesa una u otra). Y por qué hacen falta tantas copias? Pues imaginate que un ñapas se carga unas unidades de control de la copia primaria de datos. Este desastre se traslada inmediatamente a la copia secundaria de datos (que es síncrona para todo, para lo bueno y para lo malo). En este caso, puedes levantar la copia asíncrona de datos, que si bien tiene datos algo obsoletos (horas), es consistente. En cambio, la copia síncrona, se puede usar para levantar un DRC (Disaster Recovery Centre). Si tienes unos servidores junto a la copia secundaria, y en caso de que tengas un desastre en el centro primario... tienes una copia consistente de datos en las cabinas secundarias... Luego puedes tener dos (o más!) centros de datos con copias primarias, secundarias síncronas, terciarias asíncronas, interconectados con fibra oscura (DWDM) con un ancho de banda adecuado para escenarios de auténtico desastre. No sé si me explico. Como puedes ver, los temas de almacenamiento tocan, además del rendimiento de los dicos frente a la frecuencia de acceso que tienen los propios ficheros, tocan también temas de escenarios de desastre, disponibilidad y coherencia del dato (es mucho peor tener un dato inconsistente que no tenerlo en absoluto o tenerlo obsoleto). Yo acabo de descubrir este mundo... y es apasionante. Los técnicos de almacenamiento buenos suelen estar muy bien pagados... -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Hola :) El Thursday 02 October 2008, miguel gmail escribió:

...

Pero es que la situaci�n que describe Rafa es una gozada. Tu usas un "algo" con unos discos muy r�pidos. Si un archivo no se usa en bastante tiempo, ese trasto lo quita de los discos rapidos y lo pone en otros discos mayores y m�s lentos. Si sigue sin usarse en m�s tiempo lo traslada a la capa 3, m�s lenta y de mayor capacidad. Si de repente se usa, pues lo recupera en cuanto puede, tarda un poco m�s, y lo vuelve a poner en la primera capa.

Todo esto sin tener que mandar a un pringado a enchufar el backup.

je je... y esto se puede complicar hasta el infinito. Donde estoy en proyecto ahora estoy descubriendo estas cosas ahora.

Por ejemplo. Los datos ya no se guardan backup, o no necesariamente, o no como �nica soluci�n para cuando te encuentras problemas.

Pensando en escenarios de Desastre, ahora se hacen copias de los datos. Estas copias pueden ser de dos tipos: S�ncrona o As�ncrona.

Las dos copias se gestionan a nivel de cabina de discos (los servidores ni se enteran, salvo que exista algun cuello de botella en la SAN o en la LAN). Las propias cabinas de discos replican datos entre ellas, y en caso de desastre, cortan los enlaces entre ellas y se posicionan como copia primaria (o secundaria, seg�n el caso).

En el caso de copia s�ncrona de datos, las cabinas replican _instant�neamente_ cualquier dato que se escriba en la copia primaria de discos. Hasta que el dato no se ha replicado en la cabina secundaria, el servidor no recibe el ok de que el dato se ha escrito.

En el caso de la copia as�ncrona, se establecen grupos de consistencia. Cada X tiempo, se sincronizan aquellos ficheros nuevos o que hayan cambiado. En este caso existe cierto retraso hasta que se env�an los datos a la cabina con la copia as�ncrona.

Hay un tercer caso que se llama ... la verdad es que no me acuerdo cómo se llama, pero es muy útil para BBDD. Es una copia síncrona en la que se escriben en el que los bloques en el mismo orden en ambas cabinas.

En entornos grandes (muy grandes) existen los tres entornos:

- copia primaria: cabinas en una SAN donde se escriben los datos desde los servidores. - copia secundaria: cabinas en una SAN en r�plica s�ncrona con las cabinas primarias. - copia terciaria: cabinas en una SAN en r�plica as�ncrona con, o bien los datos primarios o bien los datos secundarios (estas dos configuraciones tienen pros y contras, seg�n lo que persigas y la configuraci�n que tengas te interesa una u otra).

Y por qu� hacen falta tantas copias? Pues imaginate que un �apas se carga unas unidades de control de la copia primaria de datos. Este desastre se traslada inmediatamente a la copia secundaria de datos (que es s�ncrona para todo, para lo bueno y para lo malo). En este caso, puedes levantar la copia as�ncrona de datos, que si bien tiene datos algo obsoletos (horas), es consistente.

En cambio, la copia s�ncrona, se puede usar para levantar un DRC (Disaster Recovery Centre). Si tienes unos servidores junto a la copia secundaria, y en caso de que tengas un desastre en el centro primario... tienes una copia consistente de datos en las cabinas secundarias...

Luego puedes tener dos (o m�s!) centros de datos con copias primarias, secundarias s�ncronas, terciarias as�ncronas, interconectados con fibra oscura (DWDM) con un ancho de banda adecuado para escenarios de aut�ntico desastre.

No s� si me explico. Como puedes ver, los temas de almacenamiento tocan, adem�s del rendimiento de los dicos frente a la frecuencia de acceso que tienen los propios ficheros, tocan tambi�n temas de escenarios de desastre, disponibilidad y coherencia del dato (es mucho peor tener un dato inconsistente que no tenerlo en absoluto o tenerlo obsoleto).

Esto se empezó a poner de moda a raíz de "Las Torres Gemelas" y en España a raíz del "Windsor", aunque bueno, hay de todo. Ya sabéis cómo funcionan aquí las cosas: hay empresas que ni tienen backup ;)

Yo acabo de descubrir este mundo... y es apasionante.

Los t�cnicos de almacenamiento buenos suelen estar muy bien pagados...

La verdad es que es el futuro por dos razones: 1.- la que comenta Miguel: seguridad de datos 2.- el volúmen de datos que se están manejando y la velocidad a la que se mueve todo hoy en día Cada vez está la gente más preocupada por: - poder tener la seguridad que puede acceder a TDOSO sus datos pase lo que pase - poder acceder a TODOS sus datos a tiempo Y el volumen de datos escala de unas maneras ... que no os lo podéis imaginar. Nadie borra nada, todo el mundo tiene miles de copias de miles de ficheros (la gran mayoría inútiles). Por eso ahora se está poniendo de moda la "deduplicación". La deduplicación consiste en archivar una única copia de un fichero que exista dos o más veces en disco. Esto se está aplicando sobre todo en Backups y sw de archivado, pero ya están empezando a aparecer NAS con esta tecnología. Resumiendo, que si alguien quiere buscar trabajo: que mire al tema del almacenamiento, bien sea como empresa (buscar clientes) o bien como persona (buscar un puesto de trabajo). Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

Pues eso lo hace el rsync.

No. El rsync trabaja a nivel de fichero. La réplica de datos entre sistemas de almacenamiento se hace a nivel de bloque... aunque no entiendo muy bien la diferencia entre un sistema y otro (entiendo réplica a nivel de ficheros, claro, pero no la otra). A ver si Rafa nos sabe iluminar O:-) -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-02 a las 13:53 +0200, Rafa Grimán escribió:

...

...

moda la "deduplicación".

Jo, ¡pero si eso me pasa en casa! Con tanto sitio en el disco es fácil que no sepas donde tienes cada cosa. O haces una copia para probar algo, y luego te olvidas...

Para eso están herramientas como: fdupes ;)

Tendré que mirarlo.

...

...

La deduplicación consiste en archivar una única copia de un fichero que exista dos o más veces en disco. Esto se está aplicando sobre todo en Backups y sw de archivado, pero ya están empezando a aparecer NAS con esta tecnología.

Pues eso lo hace el rsync.

rsync no hace deduplicación, lo que hace es no copiar el bloque que no se ha modificado. Lo de la deduplicación es que si el mismo fichero ya existe, no se copian las dos copias, sólo una y un puntero a la segunda copia.

No, no, no es eso. Tu hablas de la parte de transmisión de datos, que no se envian datos que ya están. Yo hablo de "--link-dest": rsync $OPTIONS --link-dest=$PREVIO/system $QUE $DESTINO/system/ Mira en la copia previa de backup que hiciste, y si el fichero existe y no ha cambiado, le hace un hardlink en el nuevo directorio. Un puntero, como dices. Es lo mismo :-)

...

...

Resumiendo, que si alguien quiere buscar trabajo: que mire al tema del almacenamiento, bien sea como empresa (buscar clientes) o bien como persona (buscar un puesto de trabajo).

Uf. Me pilla un poco tarde y/o viejo para hacer ese cambio. O:-)

Nunca se sabe ;)

No, desde luego. En cada trabajo me ha tocado aprender algo totalmente nuevo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjkvssACgkQtTMYHG2NR9VQegCfWYrikDqe/fe0s3m6+2UaHR0h gvMAnR/HDASVWtRGJqXK6ctNduYizqHb =1z2g -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-02 a las 20:08 +0200, lluis escribió:

...

La máquina en cuestion es una central telefonica, "la cinco". La(s) base puede tener cosas como qué tarjeta tiene qué abonado con qué número, o por donde se encamina una llamada de Granada a Valladolid, o si el abonado tal ha cambiado el desvío de llamada marcando un código en su terminal: obviamente la base de datos tiene que responder instantáneamente. Es mucho más pequeña que las bases de datos que tú manejarás, pero no obtante tiene muchísimos campos y tablas. Trabaja en tiempo real.

Conceoto dudoso. Segun yo entiendo un sistema de tiempo real es aquel garantiza el tiempo maximo de respuesta, aunque este sea de una semana.

Ya, lo se. Este cumple la definición. Usa un unix que llaman "Unix RTR", que significa "Real Time Reliable". Creo que una vez ojeando ví cosas como mail X'-) Llegar a la "shell" de unix en ese trasto es una operación privilegiada, no se le permite a todos los operadores; la operación normal es una especie de cuadro de menu con comandos numericos y textuales, y se puede configurar hasta el punto de definir los comandos que puede ejecutar cada usuario o clase de usuarios. Tiene un sistema de control de usuarios muy sofisticado (cuando lo activan). http://en.wikipedia.org/wiki/5ESS http://en.wikipedia.org/wiki/UNIX-RTR http://en.wikipedia.org/wiki/3B21D y aquí alguna foto, y no buenas: http://www.firsttechcommunications.com/specials/lucent/lucent.html - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjlHAIACgkQtTMYHG2NR9Wy1gCfcuWC1SLsyWSF7HEY9LubPqiV GscAniioifnyB1tKiZ+obGcBqV981p04 =aT17 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-30 a las 10:10 +0200, Camaleón escribió:

...

A los SATA, cuando les das mucha caña fallan que da gusto, especialmente si son más grandes de 500 GB.

400 gb. cada disco. Pero ¿por qué dices que fallan? ¿Y qué es lo que falla? :-?

Hay discos sata "high reliability". No veo motivo en el cambio de interfaz de scsi a sata para que el disco falle más. Fallará igual un scsi que 500 que un sata de 500 si son de la misma fiabilidad. Lo que pasa es que estarán usando discos caseros en servidores. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjiB+gACgkQtTMYHG2NR9WXXgCeJwd0GMhQ7dbmSH5CV9v6tIEG fUcAn2SuXP5o+cqnbEZztNfOGyPCds5X =EbFx -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-09-30 a las 13:22 +0200, Rafa Grimán escribió: ...

...

Lo que pasa es que estarán usando discos caseros en servidores.

Hay casos que sí usan SATA caseros para servidores (para bajar los precios, así que tened cuidado ;), pero no siempre es así.

No es sólo la conexión, es a la hora de fabricar. SCSI siempre ha estado orientado a servidores por lo que siempre se ha fabricado con más "mimo", en cambio ATA/IDE ha estado más orientado a casa.

Ya, pero yo he visto discos sata con la nota "high reliability", para servidores. Seagate, por ejemplo. Y son más caros. Si el fabricante es el mismo de uno y otro bus, no hay ningún motivo para que no fabrique discos sata de categoría servidor. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjiHDUACgkQtTMYHG2NR9XpKgCfbRxYRA8K0lcUaI6ocSlQ0LaZ JwUAn3GCIeN9KgUhcqFJz/JdjKf45L6g =jFSY -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-01 a las 12:28 +0200, Rafa Grimán escribió:

Hola :)

El Tuesday 30 September 2008, Carlos E. R. escribió:

...

El 2008-09-30 a las 13:22 +0200, Rafa Grimán escribió:

...

...

...

Lo que pasa es que estarán usando discos caseros en servidores.

Hay casos que sí usan SATA caseros para servidores (para bajar los precios, así que tened cuidado ;), pero no siempre es así.

No es sólo la conexión, es a la hora de fabricar. SCSI siempre ha estado orientado a servidores por lo que siempre se ha fabricado con más "mimo", en cambio ATA/IDE ha estado más orientado a casa.

Ya, pero yo he visto discos sata con la nota "high reliability", para servidores. Seagate, por ejemplo. Y son más caros. Si el fabricante es el mismo de uno y otro bus, no hay ningún motivo para que no fabrique discos sata de categoría servidor.

Sí, es cierto que hay SATA de categoría "Enterprise"*, pero aún así recuerda que el volumen de datos es mayor y la cabeza tiene que recorrer todo ese espacio para llegar a un dato.

Bueno, pero eso pasará indepndientemente de la tecnología del bus.

En cambio SCSI/FC/SAS siempre se ha diseñado para soportar grandes velocidades (15000 rpm) y que los cabezales estén todo el día de un lado para otro, en SATA e IDE no existe esa "tradición".

Bueno, si es por tradición... :-) Yo ya dije que tendrían que sacar los discos con varios cabezales independientes. Son capacidades muy grandes. Si quieres servir a bastantes máquinas con un sólo disco grandote, no va a poder. Si se reparte la carga entre varios discos menores, se aumenta la velocidad. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjjVmkACgkQtTMYHG2NR9XyFACfdGiAmgoTbiMYMR4k3ehQ/tUp StYAmwc24emegcvJsgEXlOXMAA3PmsI7 =LOlL -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-01 a las 11:43 -0300, Juan Erbes escribió:

Y ademas, no necesitan particionarlos en 30 particiones ... :-) En 10000 o 15000 rpm, no vas a conseguir discos de mas de 150 GB (yo consegui de 75 GB), por lo que si los vas a usar en raid, va una sola particion.

Yo no tengo ningún problema en que no puedas hacer más de 14 particiones en un disco scsi. Pa'vosotros. Yo no tengo scsis. El problema es que nos obliguen a los usuarios de otros sistemas de disco, con espacios gigantescos en un sólo disco, a forzar una limitación arbitraria que nos es ajena. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjjkdAACgkQtTMYHG2NR9XJgACfWyhLfqFvU5JQTxlJyDuP9oEm Xs8An330Awm1fqy31XhM3W3gw8tyZuaS =JrfO -----END PGP SIGNATURE-----

Hola :) El Wednesday 01 October 2008, Camaleón escribió:

...

...

En cambio SCSI/FC/SAS siempre se ha dise�ado para soportar grandes

velocidades

...

(15000 rpm) y que los cabezales est�n todo el d�a de un lado para otro, en SATA e IDE no existe esa "tradici�n".

A ver, �que el n�mero de puertos de la controladora no es infinito! Ni tampoco el del chasis / backplane... Un servidor est�ndar en rack de 2 U permite hasta 6 discos de 3'5''.

Y si quieres poner raid o te compras los armarios de 42U y "enracas" servidores de 4U con dobles controladoras o pones blades... porque con discos de 200 gb. no d� ni "pa" empezar >:-)

Para eso tienes cabinas externas de discos, para no tener que poner tanto servidor (ni tanto blade), ni repartir los sistemas de ficheros entre diferentes servidores. Te pillas un par de tarjetas PCI-X o PCIe FC (o SAS, dependiendo de la tecnología que vayas a usar), un par de cables FC (o SAS) y una cabina de discos y conectas el servidor con la cabina. Luego a la cabina le vas enchufando discos y creando RAIDs a medida que los necesitas. De esta manera puedes tener: - dos servidores (alta disponibilidad) conectados a - una cabina de discos - un único sistema de ficheros* Hay cabinas de discos que aceptan muuuuuuchos discos. Rafa * Puedes tener más sistemas de ficheros, según tus necesidades, puedes particionar la cabina por si quieres asignar diferentes volúmenes a diferentes servidores, ... -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

...

Hay cabinas de discos que aceptan muuuuuuchos discos.

¿Como se conectan dos servidores al mismo sistema de ficheros, quien manda? ¿No hay colisiones? ¿O un servidor está en espera activa/pasiva?

Es un problema con una solución 'sencilla' (sencilla porque se enmarrona al proveedor de tecnología, claro). Se llaman SAN (Storage Area Network) :http://en.wikipedia.org/wiki/Storage_area_network Son redes, normalmente, aunque no necesariamente, basadas en fibra optica. Tienes tres tipos de componentes: Servidores: Todos los servidores que necesiten acceso a esa SAN se conectan mediante Fibre Channel (ya digo, se suele usar fibra optica para este proposito, aunque no es un requermiento en sí mismo). Directores de Fibra: Suele ser al menos uno (mejor dos, por tener caminos redundantes). Son, funcionalmente hablando, switches que interconectan los servidores con las cabinas de discos. Los switches se enlazan entre ellos mediante un ISL (Inter Switch Link), para permitir que se 'hablen' entre ellos. Los típicos - o los que yo conozco - son Brocade y Cisco. Las redes, al ser de fibra, van actualmente a 2Gbps, aunque actualmente ya está disponible tecnología de 4Gbps, y se planea la siguiente generación a 10Gbps. Ten en cuenta que en una SAN hay VARIAS fibras, no una solo, por lo que el ancho de banda para guardar datos es brutal. Esto se complica mediante una funcionalidad llamada 'zoning' que viene a ser básicamente similar al subnetting en un entorno LAN, establecer ciertas zonas dentro de la SAN opacas entre sí, aunque compartan directores de fibra. Añade seguridad y mejora el rendimiento de la SAN. Cabinas de discos: Pues eso. Armarios llenos de discos, con diversos niveles de RAID, con configuraciones de LUNs, discos, etc adecuadas para optimizar el rendimiento y los costes, etc etc A esto, en ciertos entornos (sobre todo en Mainframe) se suelen añadir librerías de cartuchos (cintas), también con fibra optica (en entorno IBM, al protocolo se le llama FiCon, si bien el soporte hw creo que es idéntico a Fibre Channel). Si bien en entornos abiertos las cintas se usan sólo para backups, en Grandes Sistemas los cartuchos se usan para absolutamente todo, pero esencialmente para almacenamiento de larga duración de ficheros poco accedidos (sería como un cuarto nivel, o tier, de almacenamiento). Eso sí, las librerías de cintas son bastante más lentas que los discos duros, así que ahora se montan 'virtualizadores'. Los virtualizadores son armarios de discos con un sw determinado que se conecta a la SAN y se 'anuncia' como una librería de cintas. El Mainframe de turno le pasa los datos a guardar, y al tener en realidad discos en lugar de cintas, la velocidad de acceso es mucho más elevada. Más tarde, el virtualizador le pasa, también a través de la SAN (normalmente) los datos a la verdadera librería de cintas. ... a todo esto, ahora está de moda otra tecnología relacionada con el almacenamiento de datos: Deduplicación. Esta solución viene con dos sabores: Sólo software, o un appliance que incluye hw y sw. Lo que hace esta tecnología es leer todos los datos buscando patrones comunes de datos. Una vez encuentra esos datos comunes, en lugar de almacenar dos veces el mismo contenido, guarda una referencia a la cadena de datos allí donde hace falta. Con esta tecnología se consiguen tasas de compresión de 20:1. Donde estoy, estamos probando varios proveedores, y en un entorno de laboratorio windows (servidores de ficheros, Lotus Notes, Red Novell...) funciona de maravilla. Todavía estamos analizando proveedores, pero la idea es implementar alguna de estas soluciones con archivado de largo alcance y backup. -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

VTLs (Virtual Tape Library). También se está poniendo muy de moda en España. Lo bueno de esto es que se crean cintas "de mentira" (virtuales) en disco que tienen el mismo tamaño que la cinta física por lo que no hace falta luego andar "particionando" los datos para meterlos en la cinta sino que se vuelca todo directamente a la cinta.

Pues sí, supongo. Aquí hay alguna instalada... También se están montando cabinas de discos que virtualizan otras cabinas de discos (más antiguas). Simplifican la administración del almacenamiento. A mi me impresionan las cifras que se mueven en este entorno. Hace poco nos han pedido desde Sistemas Abiertos unas ampliaciones de almacenamiento... como hay tres entornos (copia primaria, copia sincrona y asíncrona)... pues sale la friolera de 30 TB x 3 entornos... casi 100 TB de una tacada. Bárbaro.

Vaya, si llego a leer antes este correo no lo menicono en mi correo anterior 0:)

Read first you must, little Padawan XD -- Saludos, miguel Los agujeros negros son lugares donde dios dividió por cero. Black holes are places where god divided by zero. Steven Wright -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-10-02 a las 14:01 +0200, Rafa Grimán escribió:

Volumen muy majo de discos, si Sr :)

Espero que no te pase como a mi una vez: tuve que desmontar la cabina entera y subir disco a disco todo porque los racks no cabían por las escaleras y no había ascensor. Un día entero muy entretenido.

¿Tu has visto una central telefonica por dentro, has visto los armarios que se gastan? Pues imaginate hacer "una descarga", de madrugada. Bueno, las de madrugada es que te abren una puerta de varios metros a nivel de suelo, al vacío, en el tercer piso, y suben las piezas con un camión grua. Por eso es de madrugada, porque cortan la calle. Y por si alquien tropieza en un cable y desenchufa a Vallecas, que no sea en horas de oficina :-P Pero luego están las diurnas, cuando no han pagado lo que cuesta una descarga oficial, o ya han subido enla oficial los armarios y a tí te toca el resto: tarjetas, cables, armaritos.... Como hay ese portón al exterior, no hay ascensor, y si lo hay no es de carga. A subir al tercer piso. Y son pisos preparados para un falso suelo de medio metro y un techo de cables de otro medio, más altura para armarios de dos o más metros, porque se calcularon para las conmutatrices y las pentaconta. O sea, que cada piso creo que es de cuatro o cinco metros, no los dos y pico habituales, y para aguantar toneladas en el suelo, o sea, suelos gruesos. A subir. Lo peor son los rollos de cable de fuerza. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjkwMoACgkQtTMYHG2NR9UTcACfUFRVi3YSFdoTXEcwVCp400PF +g8Ani17o01FJs8qjYnRTWHLCnOFxQgC =3jOc -----END PGP SIGNATURE-----

Hola :) El Monday 29 September 2008, Camaleón escribió:

El 29/09/08, Rafa Grim�n escribi�:

...

Menos mal que est�s tu porque no hab�a ca�do en esto 0:) Vamos que nos vale con un floppy ;)

Grrr.

Est� bien, est� bien... voy a llamar a Telef�nica (ring, ring) para que os baje el ancho de banda de 3/6 megas a 1... total, si no os hace falta �no? >:-)

Tranquila ... Lo que quería decir es que con tanto tráfico por la red ... se va a parecer eso a la hora punt de cualquier ciudad ;)

...

No hombre, no. No son tan caros, los de FC s� son caros, los SAS son m�s baratos. A lo mejor como para tener 2 TB en casa no (actualmente son de hasta 400 GB), pero s� son m�s baratos.

Yo, personalmente, creo que no llego a los 300 GB de morralla en mis discos ... la verdad es que si me pongo a hacer limpieza seguro que se queda en unos 200 GB. As� que no veo SAS como mala opci�n para mi.

La pega que le veo a los sas es la "compatibilidad".

Pos tienen mucha compatibilidad: si tienes controladora SAS, puedes enchufar discos SAS _Y_ SATA !!! SAS es la evolución de SCSI. SAS es a SCSI lo que SATA es a IDE/ATA. Es decir, SAS es Serial Attached SCSI. Es decir, cuando eramos jóvenes, teníamos SCSI (para los que querían más renidmiento, garantía de ancho de banda, ...) y ATA/IDE para los que nos traía sin cuidado (o no teníamos dinero). Pues sustituye la palabra "SCSI" por "SAS" y la palabra "ATA/IDE" por "SATA" en el párrafo de arriba y estarás en el Siglo XXI ;) Es lo mismo, pero antes era en paralelo y ahora es en serie. Pero la filosofía es la misma.

Es decir, con los discos magneto �pticos me pas� lo mismo: eran una buena alternativa pero nadie ten�a unidades lectoras y no pod�a llevarlos a ning�n lado por lo que s�lo los us�bamos a modo de copia de seguridad :-(.

Pero no eran la evolución de un producto ya consolidado. Ten en cuenta que SCSI (los comandos) se usan en FC y SAS e incluso ahora el kernel de Linux usa SCSI por defecto (recuerda los CD-RW al principio de los tiempos, que había que emular SCSI y rezar a la luz de las velas mientras ponías velas y estabas en ayunas ;) SCSI, como tal no va a desaparecer (el mundo del almacenamiento depende mucho de SCSI), evolucionará ... hasta que un día sea algo completamente diferente ;")

Y ahora tengo problemas con los scsi... �"ande" los pincho? :-? Necesito cajas externas scsi-usb para conectarlos porque la mayor�a de equipos que ten�an adaptadores scsi (integrados en la placa o con tarjeta) est�n pasando a la reserva por tener m�s de 5 a�os...

Se pueden comprar tarjetas PCIX SCSI aún ... si quieres te vendo una ;) Mucha gente usa aún SCSI (que no SAS). Muchas librerías de cintas siguen usando SCSI para conectarse a los servidores, especialmente las pequeñas. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El día 28 de septiembre de 2008 17:01, Camaleón escribió:

El 28/09/08, pedro Marquina escribió:

...

la había leído y se comenta en diferentes foros, pero esa velocidad (que es estupenda) no está soportada por la mayoría de los discos duros, que suele ser de 70 u 80 KB.

Ya veo que querías decir MB. Pero ojo que el sata 300 tiene una tasa de transferencia de hasta 300 MB/s y la nueva especificación sube hasta los 6 Gb/s (si no vuelvo a meter la pata con las unidades...).

Estas cifras que siempre confunden... No es lo mismo 300 megabits/seg, que 300 megabytes/seg. La verdad, es que no conozco ningun disco duro que transfiera 300 megabytes en un segundo. Y menos aun, en 7200 rpm. Lamentablemente, hay ciertas practicas engañosas en la forma de especificar, como el tomar 1 megabyte= 1000000 bytes, cuando en la practica, 1 megabyte= 1024000 bytes, o lo antes citado, de hacer pasar megabits por megabytes, o gigabits por gigabytes en velocidades de transmisión. http://www.tomshardware.com/reviews/hitachi-western-digital-terabyte,2017-2.... Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 29/09/08, Juan Erbes escribió:

La verdad, es que no conozco ningun disco duro que transfiera 300 megabytes en un segundo. Y menos aun, en 7200 rpm.

Psé... en 2 / 3 años, ya veremos >:-) Además, tampoco están tan mal las cifras actuales: Average Read Transfer Performance http://www.tomshardware.com/charts/hard-disks/average-read-transfer-performa...

Lamentablemente, hay ciertas practicas engañosas en la forma de especificar, como el tomar 1 megabyte= 1000000 bytes, cuando en la practica, 1 megabyte= 1024000 bytes, o lo antes citado, de hacer pasar megabits por megabytes, o gigabits por gigabytes en velocidades de transmisión.

No hay nada engañoso. Este tema además salió hace poco y se puso una de esas tablas de la wiki que son tan majas: Gigabit Ethernet (1000base-X) 1,000 Mbit/s 125 MB/s http://en.wikipedia.org/wiki/List_of_device_bandwidths#Local_area_network Serial ATA (SATA-300) 3,000 Mbit/s 375 MB/s http://en.wikipedia.org/wiki/List_of_device_bandwidths#Computer_buses_.28sto... Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El 29/09/08, Juan Erbes escribió:

Tendras que mudarte a Japon entonces, aunque dudo mucho de que estes en condiciones de afrontar el costo de vida que tienen alla.

No es tanto como lo pintan. Hay que tener en cuenta los datos*: Japón: Tasa de paro (3,9%) / Renta per cápita de 33.600$ España: Tasa de paro (8,3%) / Renta per cápita de 30.100$ Y los precios no se disparan tanto (salvo la alimentación que sí es más cara), pero los sueldos son también más elevados. Te pongo un ejemplo. Allá por 1994, un maestro de primaria (colegio público) cobraba unos 330.000 yenes mientras que un maestro de primaria aquí en España tenía un sueldo de unas 215.000 pesetas. Ahora, con la entrada del euro en España y el aumento del paro en Japón (en 1994 era más baja aún), no sé cómo estará :-? Pero no, la vida no es "excesivamente" cara y hay trabajo... eso sí, es muy duro: vacaciones un par de semanas al año y fiestas las justas (año nuevo y alguna más... eso de los puentes -fiesta de jueves a domingo- que se hacen aquí en España les es desconocido :-P). Jornada laboral de lunes a sábado (incluso algunos escolares van al colegio los domingos)...

Otra de las paradojas normativas en lo que hace a tecnologia, por parte del gobierno, es que aun no han definido que estandar utilizar para la HDTV, si la norma japonesa, o la norteamericana. Por un lado, hay cierta inclinación por parte del gobierno hacia la norma japonesa, que habria adoptado Brasil, y el gobierno es partidario de brindar un servicio gratuito de TV digital por aire, pero sucede que con la norma japonesa, es mucho mas complicado hacer la transmision por aire en UHF, ya que de por si no viene preparada para ese servicio. http://www.pagina12.com.ar/diario/economia/2-112011-2008-09-22.html

Curioso que aún no hayan decidido... :-? Creo que a Argentina le convendría más usar el estándar norteamericano. No lo digo en cuanto a características técnicas (desconozco las ventajas de uno u otro) pero al menos para conseguir componentes os resultaría más sencillo (creo, vamos...). Supongo que la decisión no deja de ser una mera cuestión "política" más... * https://www.cia.gov/library/publications/the-world-factbook/index.html Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org