David Moreno wrote:

Buenos días a tod@s.

Tras experimentar con los servidores DNS, he decidido empezar mi camino con los servidores de ficheros. Les escribo para pedirles consejo sobre cual escoger. Lo que deseo es un sistema de almacenamiento de datos y copias de seguridad de ficheros demtro de una LAN, la plataforma que corran las maquinas clientes debe ser indiferente, es decir compatibilidad con OSX, WIN, Linux, BSD etc.. Los clientes deben acceder al sistema de ficheros de forma trasparente, como si de una carpeta o unidad más se tratara. Había pensado en SAMBA. Gracias por su tiempo. Saludos

Si tienes que interoperar con Windows, no te queda otra que usar samba. Si por el contrario las estaciones windows son versiones servidor (2003/2008/2008R2), no hay ningún problema por el cual no usases NFS y todo sigue siendo igual de transparente. Ahora bien aquí lo importante es saber que tipo de datos vas a almacenar y cantidad de clientes a conectar. Porque la decisión realmente importante que debes tomar es el tipo de filesystem a usar en el servidor y su parametrización. Saludos. -- CL Martinez carlopmart {at} gmail {d0t} 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

Se conectarian menos de 4 clientes, trabajaríamos con dos tipos de datos: Ficheros pequeños de menos de 10 MB para los documentos y ficheros de de mas de 1GB para las copias de seguridad. Dispongo de un disco de sistema y 4 discos (actualmente vacíos) para un RAID 5 en el que almacenar la información. Ademas dispongo de un disco externo para copias de seguridad adicionales. ¿Que me aconsejas? Saludos. El 23/10/09, carlopmart escribió:

David Moreno wrote:

...

Buenos días a tod@s.

Tras experimentar con los servidores DNS, he decidido empezar mi camino con los servidores de ficheros. Les escribo para pedirles consejo sobre cual escoger. Lo que deseo es un sistema de almacenamiento de datos y copias de seguridad de ficheros demtro de una LAN, la plataforma que corran las maquinas clientes debe ser indiferente, es decir compatibilidad con OSX, WIN, Linux, BSD etc.. Los clientes deben acceder al sistema de ficheros de forma trasparente, como si de una carpeta o unidad más se tratara. Había pensado en SAMBA. Gracias por su tiempo. Saludos

Si tienes que interoperar con Windows, no te queda otra que usar samba. Si por el contrario las estaciones windows son versiones servidor (2003/2008/2008R2), no hay ningún problema por el cual no usases NFS y todo sigue siendo igual de transparente.

Ahora bien aquí lo importante es saber que tipo de datos vas a almacenar y cantidad de clientes a conectar. Porque la decisión realmente importante que debes tomar es el tipo de filesystem a usar en el servidor y su parametrización.

Saludos.

-- CL Martinez carlopmart {at} gmail {d0t} 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 cielo es para los dragones lo que el agua es para las ninfas" -- 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

On Friday 23 October 2009 13:35:28 Camaleón wrote:

El 2009-10-23 a las 12:52 +0200, David Moreno escribió:

...

Tras experimentar con los servidores DNS, he decidido empezar mi camino con los servidores de ficheros. Les escribo para pedirles consejo sobre cual escoger.

Lo que deseo es un sistema de almacenamiento de datos y copias de seguridad de ficheros demtro de una LAN, la plataforma que corran las maquinas clientes debe ser indiferente, es decir compatibilidad con OSX, WIN, Linux, BSD etc..

rsync te funciona en todas las plataformas Bacula http://www.bacula.org/en/dev-manual/Supported_Operating_Systems.html

El protocolo a usar también va en función del tipo de sistema que vayas a utilizar para hacer ese backup. Por ejemplo, hay programas dedicados que sólo trabajan mediante ftp o ssh y no permiten almacenar los datos de la copia directamente en un medio samba.

¿Qué programa has pensado para hacer esas copias de seguridad?

...

Los clientes deben acceder al sistema de ficheros de forma trasparente, como si de una carpeta o unidad más se tratara. Había pensado en SAMBA.

Samba es lento. Muy lento.

¿?¿¿??? En mi red es mas rapido que la velocidad de grabacion en los discos duros. Claro que siempre y cuando no haya 50 tirando del servidor

Si lo quieres sólo para almacén de datos (no te interesa compartir impresoras), yo te recomendaría alguna otra cosa (ssh o ftps).

ssh si que es lento como para morirse :)) saludillos -- 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 2009-10-23 a las 13:49 +0200, francisco f escribió:

On Friday 23 October 2009 13:35:28 Camaleón wrote:

...

...

Lo que deseo es un sistema de almacenamiento de datos y copias de seguridad de ficheros demtro de una LAN, la plataforma que corran las maquinas clientes debe ser indiferente, es decir compatibilidad con OSX, WIN, Linux, BSD etc..

rsync te funciona en todas las plataformas

Bacula http://www.bacula.org/en/dev-manual/Supported_Operating_Systems.html

Para pocos equipos (<10) no lo veo adecuado. Te cuesta más ponerlo en marcha que hacer la copia :-P

...

El protocolo a usar también va en función del tipo de sistema que vayas a utilizar para hacer ese backup. Por ejemplo, hay programas dedicados que sólo trabajan mediante ftp o ssh y no permiten almacenar los datos de la copia directamente en un medio samba.

¿Qué programa has pensado para hacer esas copias de seguridad?

...

Los clientes deben acceder al sistema de ficheros de forma trasparente, como si de una carpeta o unidad más se tratara. Había pensado en SAMBA.

Samba es lento. Muy lento.

¿?¿¿???

En mi red es mas rapido que la velocidad de grabacion en los discos duros. Claro que siempre y cuando no haya 50 tirando del servidor

En mi red va pasable. En un entorno casero... es otra cosa :-)

...

Si lo quieres sólo para almacén de datos (no te interesa compartir impresoras), yo te recomendaría alguna otra cosa (ssh o ftps).

ssh si que es lento como para morirse :))

Claro, por eso es uno de los protocolos de red "menos" utilizados ¿ein? >:-) Ssaludos, -- 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

Os explico en que consiste el juego: Mis amigos, a los que tantas veces he reparado su pc domestico, cansado de oir mis quejas sobre las maquinas virtuales y el mal oliente Nat que realizan, decidieron regalarme una maquina seminueva sacada de alguna tienda de segunda mano: 2GB de ram ddr2 AMD Atlon X2 a 2 Ghz. 4 Discos de 80 GB 2 SATA 2 IDE Los discos son idénticos dos a dos. No tengo lector de CD/DVD A lo que he añadido un pendrive de 4 GB y un disco Externo de 200 GB. Opensuse esta corriendo desde el pen de 4 GB, la instalación la realicé desde otro pen de 600 MB y la instalación desde la red, siguiendo este manual: http://en.opensuse.org/SuSE_install_from_USB_drive Los discos sata me los reconoce como md0 (raid) independientemente de lo yo ponga en la bios y de cree un raid o no, siempre me apare como como raid0 he creado otro raid0 con los otros dos discos IDE y a su vez un raid1 de los dos raid0 anteriores. Creo que a esto se le denomina raid5. Están vacíos y no he aplicado ningún sistema de ficheros con lo cual si esta configuración no es correcta se puede cambiar sin problemas. Tengo un viejo Mac, un win y un Linux (con opensuse) La idea es que los documentos de la familia, fotos y demás dejen de estar almacenados en una maquina y estén disponibles para todas. Si, el camino facil es compartir carpetas en red, prefiero aprender un poco más sobre como se gestionan servidores de ficheros. Además deseo almacenar copias de seguridad de los sistemas anteriores en el disco externo por si las moscas. Es lo más parecido a un sistema de producción, si un sysadmin pierde una base de datos le despiden.... si pierdo las fotos del bautizo de mi hermano no habrá lugar en el mundo donde esconderme, mi madre me encontrara ;) Saludos :) -- "El cielo es para los dragones lo que el agua es para las ninfas" -- 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

David Moreno wrote:

Os explico en que consiste el juego:

Mis amigos, a los que tantas veces he reparado su pc domestico, cansado de oir mis quejas sobre las maquinas virtuales y el mal oliente Nat que realizan, decidieron regalarme una maquina seminueva sacada de alguna tienda de segunda mano:

2GB de ram ddr2 AMD Atlon X2 a 2 Ghz. 4 Discos de 80 GB 2 SATA 2 IDE Los discos son idénticos dos a dos. No tengo lector de CD/DVD

A lo que he añadido un pendrive de 4 GB y un disco Externo de 200 GB. Opensuse esta corriendo desde el pen de 4 GB, la instalación la realicé desde otro pen de 600 MB y la instalación desde la red, siguiendo este manual:

http://en.opensuse.org/SuSE_install_from_USB_drive

Los discos sata me los reconoce como md0 (raid) independientemente de lo yo ponga en la bios y de cree un raid o no, siempre me apare como como raid0 he creado otro raid0 con los otros dos discos IDE y a su vez un raid1 de los dos raid0 anteriores. Creo que a esto se le denomina raid5. Están vacíos y no he aplicado ningún sistema de ficheros con lo cual si esta configuración no es correcta se puede cambiar sin problemas.

Tengo un viejo Mac, un win y un Linux (con opensuse)

La idea es que los documentos de la familia, fotos y demás dejen de estar almacenados en una maquina y estén disponibles para todas. Si, el camino facil es compartir carpetas en red, prefiero aprender un poco más sobre como se gestionan servidores de ficheros. Además deseo almacenar copias de seguridad de los sistemas anteriores en el disco externo por si las moscas. Es lo más parecido a un sistema de producción, si un sysadmin pierde una base de datos le despiden.... si pierdo las fotos del bautizo de mi hermano no habrá lugar en el mundo donde esconderme, mi madre me encontrara ;) Saludos :)

Sigues sin decirme que tipo de windows es, porque podrías usar directamente nfs y te simplificas la configuración una barbaridad y no necesitarias usar samba. Yo de entrada, desharía ese raid5, penaliza demasiado. Yo haria raid para IDE y otro para SATA. Otra decision es como hacerlos, todo depende de tus necesidades de espacio y la redundancia que le quieras dar. ¿A que te refieres con "Si, el camino facil es compartir carpetas en red, prefiero aprender un poco más sobre como se gestionan servidores de ficheros"? ¿No és eso precisamente lo que quieres hacer, compartir tus discos? ¿o es que quieres saber específicamnete como hacer las cosas con samba, o nfs, o iscsi, u otra tecnología? -- CL Martinez carlopmart {at} gmail {d0t} 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 :) On Friday 23 October 2009 14:31:11 Camaleón wrote:

El 2009-10-23 a las 13:49 +0200, francisco f escribió:

...

On Friday 23 October 2009 13:35:28 Camaleón wrote:

[...]

...

...

...

Los clientes deben acceder al sistema de ficheros de forma trasparente, como si de una carpeta o unidad más se tratara. Había pensado en SAMBA.

Samba es lento. Muy lento.

¿?¿¿???

En mi red es mas rapido que la velocidad de grabacion en los discos duros. Claro que siempre y cuando no haya 50 tirando del servidor

En mi red va pasable.

¿Samba lento? Eso es que la red y/o el servidor no están bien dimensionados ;)

En un entorno casero... es otra cosa :-)

...

...

Si lo quieres sólo para almacén de datos (no te interesa compartir impresoras), yo te recomendaría alguna otra cosa (ssh o ftps).

ssh si que es lento como para morirse :))

Claro, por eso es uno de los protocolos de red "menos" utilizados ¿ein?

...

:-)

SSH es "lento" si no tenemos una CPU potente, recordemos que cifra y es donde se "pierde tiempo". HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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 :) On Sunday 25 October 2009 21:32:38 Camaleón wrote:

El 2009-10-25 a las 20:32 +0100, Rafa Grimán escribió:

...

On Friday 23 October 2009 14:31:11 Camaleón wrote:

...

El 2009-10-23 a las 13:49 +0200, francisco f escribió:

...

On Friday 23 October 2009 13:35:28 Camaleón wrote:

[...]

...

...

...

...

Los clientes deben acceder al sistema de ficheros de forma trasparente, como si de una carpeta o unidad más se tratara. Había pensado en SAMBA.

Samba es lento. Muy lento.

¿?¿¿???

En mi red es mas rapido que la velocidad de grabacion en los discos duros. Claro que siempre y cuando no haya 50 tirando del servidor

En mi red va pasable.

¿Samba lento? Eso es que la red y/o el servidor no están bien dimensionados ;)

Bueno, no todos tenemos "Octanes2" en casa >:-P

Eh! Que ya vamos por la Octane III :) Un poco de "Spam": http://www.sgi.com/products/workstations/octaneIII/

Yo lo noto muy lento, cuando copio archivos "grandes" (>4 GiB.) en una red 10/100 y con equipos normalitos. El fish:// o sftp:// funciona mucho mejor.

Es que 10/100 es poco ;) Samba consume bastante CPU y RAM (1 proceso por cliente). ssh consume menos RAM. Otra cosa, transfiriendo ficheros grandes y con redes 1 Gbps es recomendable usar jumbo frames (con 100 Mbps no valen los jumbo frames). Ahora, eso sí, tienes que activar jumbo frames en TODOS los equipos conectados al switch. Lo de que el fish o el sftp funciona mejor ... ¿números/tiempos? Sólo curiosidad por saber cuánto mejor funciona.

No sé, quizá es kde, opensuse o alguna otra configuración que se me escapa (¿netbios activado?) pero desde luego samba no es el más rápido del oeste.

NFS da mejor rendimiento con el mismo hardware.

...

...

En un entorno casero... es otra cosa :-)

...

...

Si lo quieres sólo para almacén de datos (no te interesa compartir impresoras), yo te recomendaría alguna otra cosa (ssh o ftps).

ssh si que es lento como para morirse :))

Claro, por eso es uno de los protocolos de red "menos" utilizados ¿ein?

...

:-)

SSH es "lento" si no tenemos una CPU potente, recordemos que cifra y es donde se "pierde tiempo".

Eso, y encima ssh te añade el cifrado "gratis" :-P

Ná, es que samba no me gusta nada... ¿se nota mucho? O:-)

Noooooo ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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 23/10/09, Camaleón escribió:

El 2009-10-23 a las 13:45 +0200, David Moreno escribió:

...

El 23/10/09, Camaleón escribió:

...

¿Qué programa has pensado para hacer esas copias de seguridad?

Me has pillado... no había pensado en ello todavía, no conozco muchos programas y pensaba hacerlas a mano en, se nota que soy novatillo.

Te comento cómo lo tengo yo, por si te sirve de orientación. No es un sistema que me guste o recomiende al 100% pero mientras encuentro algo mejor, lo mantengo.

Tengo dos redes, A y B.

En la red A, las estaciones de trabajo (clientes) usan windows xp y el servidor está bajo suse. En esta red uso samba, y los clientes gestionan las copias de seguridad con el programa que tiene windows.

Las copias completas se hacen cada mes, las diferenciales cada semana (los equipos montan raid1 y tienen su propio disco local para datos).

[...] Este esquema, red A, creo que es lo más aproximado a lo que busco, Aunque mi red es 10/100 una montado el sistema haré algunas pruebas. El 23/10/09, carlopmart escribió:

Sigues sin decirme que tipo de windows es, porque podrías usar directamente nfs y te simplificas la configuración una barbaridad y no necesitarias usar samba.

XP home, los servicios Unix para win están disponibles para las ediciones de servidor y para los vista y sucesores, Corrígeme si me equivoco porque me resulta un poco confuso: http://www.suacommunity.com/FAQs.aspx#100 Si realmente se puede utilizar NFS con XP home creo que si, resultaría más sencillo.

Yo de entrada, desharía ese raid5, penaliza demasiado. Yo haria raid para IDE y otro para SATA. Otra decision es como hacerlos, todo depende de tus necesidades de espacio y la redundancia que le quieras dar.

Carlos también ha manifestado su opinión en cuanto a la construcción del Raid 5, más adelante lo tratamos.

[...] ¿o es que quieres saber específicamente como hacer las cosas con samba, o nfs, o iscsi, u otra tecnología?

Ese es precisamente el objetivo, el aprendizaje y puesta en funcionamiento de un servidor de ficheros a nivel local, que además proporcione un servicio de utilidad a mi familia dentro de un entorno de producción domestico. Anteriormente he experimentado con otro tipo de servicios como DNS, DHCP, TFTP y FTP con la ayuda de esta lista de correo. Gracias a todos por dedicarme un poco de vuestro tiempo y ayudarme a crecer intelectualmente en el ámbito de la informática. El 23/10/09, Carlos E. R. escribió:

No.

Es un raid 1 sobre raid0 (¿0?). Si el primero es un raid 0 y no 1, ni ese primero ni siquiera es raid, son dos discos concatenados.

Raid 5 es un único nivel con tres o más discos.

Voy a tratar de reproducir la tabla de particiones que aparece en Yast, disculpen si el sangrado no es correcto: Device SIZE TYPE FS Mount point /dev/mapper/nvidia_cbhibedb 149,06GB DM RAID nvidia_cbhibedb /dev/sda 74,53GB ST380811AS /dev/sdb 74,53GB ST380815AS /dev/sdc 74,53GB ST380811A /dev/sdc1 74,52GB Linux RAID /dev/sdd 74,53GB ST380811A /dev/sdd1 74,52GB Linux RAID /dev/sde 3,77GB USB DISK 2.0 /dev/sde1 635,35MB Linux swap /dev/sde2 3,14GB Linux Native Ext3 swap /dev/md0 149,04GB MD RAID Ext3 / El Dispositivo /dev/mapper/nvidia_cbhibedb 149,06GB DM RAID nvidia_cbhibedb lo reconoce como un raid0 o discos concatenados. Lo hace independientemente de que la bios le especifique que los discos SATA los utilice en modo IDE, RAID o ACHI y de que cree un array 0 o 1 en la bios de configuración del raid NVIDIA. La placa madre es: http://www.asrock.com/mb/overview.la.asp?Model=AM2NF6G-VSTA La Idea es crear un sistema de redundancia por si algún disco falla en caliente poder seguir funcionando sin detener el servidor, para las copias de seguridad dispongo de una unidad externa que no está reflejada en la tabla anterior. Cualquier sugerencia será bien recibida. El 26/10/09, Rafa Griman escribió:

Hola :)

Eh! Que ya vamos por la Octane III :) Un poco de "Spam":

http://www.sgi.com/products/workstations/octaneIII/

Rafa, por Tutatis, no me enseñes esos "mostruitos" que luego tengo limpiar las babas del teclado ;) El 26/10/09, Camaleón escribió: [...]

Ese no lo he probado... ¿es complicado de configurar, como samba? :-?

Pues si las aplicaciones son compatibles con XP, lo pruebo y posteo los datos de tasa de transferencia etc... del sistema

Creo que windows tiene una utilidad dentro del paquete de herramientas de servicios para unix que permite trabajar con unidades nfs.

SUA, incluye una terminal, y algo he leído sobre compilación pero no me hagas mucho caso, yo en esto de la lengua inglesa soy autodidacta.

Reconozco que samba es útil, pero si sólo hay transferencia de archivos de por medio y no es necesario compartir impresoras o pertenencer a dominio, pues me lo pensaba dos veces.

No hay dominio de win ni impresoras para compartir, solo ficheros para servir. Saludos :) -- "El cielo es para los dragones lo que el agua es para las ninfas" -- 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 :) On Monday 26 October 2009 11:32:59 Camaleón wrote:

El 2009-10-26 a las 09:06 +0100, Rafa Grimán escribió:

...

On Sunday 25 October 2009 21:32:38 Camaleón wrote:

...

...

...

En mi red va pasable.

¿Samba lento? Eso es que la red y/o el servidor no están bien dimensionados ;)

Bueno, no todos tenemos "Octanes2" en casa >:-P

Eh! Que ya vamos por la Octane III :) Un poco de "Spam":

http://www.sgi.com/products/workstations/octaneIII/

¡Menudos monstruitos! :-)

Hum... curioso que el modelo de una vía utilice el chipset 945GC (¿lakeport?) :-?

No te sé decir el por qué y aque no soy el Product Manager 0:) De todas maneras, son clusters para tener debajo de la mesa (deskside clusters) que empiezan con 8 cores (Xeon) o bien 2 cores (Atom).

...

...

Yo lo noto muy lento, cuando copio archivos "grandes" (>4 GiB.) en una red 10/100 y con equipos normalitos. El fish:// o sftp:// funciona mucho mejor.

Es que 10/100 es poco ;) Samba consume bastante CPU y RAM (1 proceso por cliente). ssh consume menos RAM.

Otra cosa, transfiriendo ficheros grandes y con redes 1 Gbps es recomendable usar jumbo frames (con 100 Mbps no valen los jumbo frames). Ahora, eso sí, tienes que activar jumbo frames en TODOS los equipos conectados al switch.

Lo de que el fish o el sftp funciona mejor ... ¿números/tiempos? Sólo curiosidad por saber cuánto mejor funciona.

Números rápidos... archivo de 175 MB (red 10/100, cliente: 3 GB de ram, pentium core 2 quad - servidor: 3 GB de ram, Pentium D):

Cliente suse -> servidor suse (samba): tasa 7,1 MB/s Cliente suse -> servidor suse (sftp): tasa 6,8 MB/s

Grrr... ¡Pero el sftp no se atranca! :-)

ROFL. No pretendía que fuera esto una "demostración". Era sólo curiosidad 0:) De todas maneras, no se van mucho los números, sólo hay una diferencia de 0.3 MB/s.

Copiando mediante samba (archivos más grandes) se para, va a saltos (aunque no es constante, sí hace "parones").

En cambio, usando sftp o fish la copia es más... ¿fluida?. No sé, quizá tengo que revisar las opciones del samba, no lo he tuneado mucho (más bien "nada").

Curioso, se me ocurre que con ssh (fish, scp, sftp) el cliente tiene que cifrar los datos por lo que los envía más despacio (los paquetes). En cambio, con Samba el envío es inmediato (no hay que cifrar y "descifrar") por lo que llenas los buffers (RAM) más deprisa y no da tiempo a escribir a disco. Obviamente esto son ideas que se me ocurren de buenas a primeras sin ningún tipo de demostración científica. Habría que monitorizar el cliente y el servidor (IOPS, RAM, red y CPU). Hacer muchas mediciones y luego sacar estadísticas. Vamos que no merece la pena ;) Claro que si tienes tiempo libre ... ;)

...

...

No sé, quizá es kde, opensuse o alguna otra configuración que se me escapa (¿netbios activado?) pero desde luego samba no es el más rápido del oeste.

NFS da mejor rendimiento con el mismo hardware.

Ese no lo he probado... ¿es complicado de configurar, como samba? :-?

Nop, es bastante sencillo (IMHO).

Creo que windows tiene una utilidad dentro del paquete de herramientas de servicios para unix que permite trabajar con unidades nfs.

Sí, creo que se llama SFU o algo así. Nunca lo he probado así que no sé qué rendimiento dará Windows NFS.

...

...

...

...

...

ssh si que es lento como para morirse :))

Claro, por eso es uno de los protocolos de red "menos" utilizados ¿ein?

...

:-)

SSH es "lento" si no tenemos una CPU potente, recordemos que cifra y es donde se "pierde tiempo".

Eso, y encima ssh te añade el cifrado "gratis" :-P

Ná, es que samba no me gusta nada... ¿se nota mucho? O:-)

Noooooo ;)

O:-P

Reconozco que samba es útil, pero si sólo hay transferencia de archivos de por medio y no es necesario compartir impresoras o pertenencer a dominio, pues me lo pensaba dos veces.

Samba es muy pesado de configurar (especialemnte si tienes un AD o servidores PDC) y encima, no hace reconexiones si pierdes el servidor. Es decir, si tienes dos Samba en HA y uno cae, el otro no retoma la conexión del cliente sino que el cliente tiene que reconectar (volver a hacer doble click). En el caso de NFS, se balancea esa conexión abierta por lo que el cliente no se entera que se ha caido el servidor. Hasta donde yo sé, esto es una limitación del protocolo/estándar SMB/CIFS. Smaba no es la panacea, pero si tienes clientes Windows por en medio ... casi no te queda más remedio :( Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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

Camaleón wrote:

El 2009-10-26 a las 13:00 +0100, carlopmart escribió:

...

No, con XP Home no puedes usar NFS. Solo se puede usar en ediciones de servidor y creo que con Windows 7 y vista. Si me equivoco, que alguien me corrija.

Pariendo de la base de que hablo de "oídas" porque no he tenido que montar ningún nfs:

CÓMO: Instalar el cliente para NFS en Windows para una migración de UNIX a Windows http://support.microsoft.com/kb/324055

Ahora bien, desconozco si sigue vigente ese KB.

Anda mira, tienes razón está soportado el XP Professional, no lo sabía. De todas formas creo que David ha hablado de un XP Home, o sea que está igual...

...

...

Ese es precisamente el objetivo, el aprendizaje y puesta en funcionamiento de un servidor de ficheros a nivel local, que además proporcione un servicio de utilidad a mi familia dentro de un entorno de producción domestico. Anteriormente he experimentado con otro tipo de servicios como DNS, DHCP, TFTP y FTP con la ayuda de esta lista de correo. Gracias a todos por dedicarme un poco de vuestro tiempo y ayudarme a crecer intelectualmente en el ámbito de la informática. Bueno la cosa es sencilla: si hay Windows de versiones iguales a XP o inferiores involucrado DEBES (lo de mayúsculas no es que esté gritando, estoy resaltando) usar samba para la compartición de archivos. Ahora bien, si los Windows fuesen 2003/2008/2008R2/Windows7, no necesitarias samba para nada, lo harías todo con NFS.

No *debe* usar samba, *puede* usar FTP o ssh, hay alternativas al cifs >:-)

Me refería a si quería hacerlo de una forma más bien transparente. Por si por ejemplo su madre, su hermano u otra persona sin tener ni idea de informática quería consultar un archivo. Persolmente, no puedo considerar a ftp o ssh una solución de compartición de archivos ... ojo, apreciación personal.

...

De todas formas puestos a aprender, mi consejo es que te mires a parte de NFS, la compartición de archivos distribuidos como AFS, el propio DFS de Windows, etc. ¿Porque? Porque samba con el tiempo será algo "residual", me explico: samba será usado en redes muy pequeñas para actuar como AD en substitución de servidores Windows, pero no ya para compartición de archivos ni impresoras, porque en estos momentos ya se puede trabajar (de hecho desde el SP2 de Windows 2003) en entornos de producción con NFS sin problemas y con muy pocas incidencias. Es otra idea que copiarán los sistemas medios de los grandes sistemas como ha sucedido con la virtualización.

¿Cómo se comparte una impresora de faxes o de pdf vía NFS?

Eso con el tiempo va a dejar de ser necesario de la forma en la que los conoces ahora. Por ejemplo los faxes irán por IP (o sea que ya no necesitas los servicios cifs por ahí) y lo de las impresoras PDF, ¿te refieres a la conversión de docs bien office u openoffice a pdf? Si es por eso, tanto windows como linux como Mac lo hacen ya out-of-the-box ...

Saludos,

-- CL Martinez carlopmart {at} gmail {d0t} 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 2009-10-26 a las 13:22 +0100, carlopmart escribió:

Camaleón wrote:

...

El 2009-10-26 a las 13:00 +0100, carlopmart escribió:

...

...

No, con XP Home no puedes usar NFS. Solo se puede usar en ediciones de servidor y creo que con Windows 7 y vista. Si me equivoco, que alguien me corrija. Pariendo de la base de que hablo de "oídas" porque no he tenido que montar ningún nfs: CÓMO: Instalar el cliente para NFS en Windows para una migración de UNIX a Windows http://support.microsoft.com/kb/324055 Ahora bien, desconozco si sigue vigente ese KB.

Anda mira, tienes razón está soportado el XP Professional, no lo sabía. De todas formas creo que David ha hablado de un XP Home, o sea que está igual...

El XP home está muy limitado :-(

...

...

Bueno la cosa es sencilla: si hay Windows de versiones iguales a XP o inferiores involucrado DEBES (lo de mayúsculas no es que esté gritando, estoy resaltando) usar samba para la compartición de archivos. Ahora bien, si los Windows fuesen 2003/2008/2008R2/Windows7, no necesitarias samba para nada, lo harías todo con NFS.

...

No *debe* usar samba, *puede* usar FTP o ssh, hay alternativas al cifs

...

:-)

Me refería a si quería hacerlo de una forma más bien transparente. Por si por ejemplo su madre, su hermano u otra persona sin tener ni idea de informática quería consultar un archivo.

Hay clienets gráficos para todas las opciones, incluso integrados en el navegador.

Persolmente, no puedo considerar a ftp o ssh una solución de compartición de archivos ... ojo, apreciación personal.

Bueno, la mayoría de discos multimedia que están tan de moda ahora oferecen samba y ftp. SSH sería "demasié" :-)

...

...

De todas formas puestos a aprender, mi consejo es que te mires a parte de NFS, la compartición de archivos distribuidos como AFS, el propio DFS de Windows, etc. ¿Porque? Porque samba con el tiempo será algo "residual", me explico: samba será usado en redes muy pequeñas para actuar como AD en substitución de servidores Windows, pero no ya para compartición de archivos ni impresoras, porque en estos momentos ya se puede trabajar (de hecho desde el SP2 de Windows 2003) en entornos de producción con NFS sin problemas y con muy pocas incidencias. Es otra idea que copiarán los sistemas medios de los grandes sistemas como ha sucedido con la virtualización.

...

¿Cómo se comparte una impresora de faxes o de pdf vía NFS?

Eso con el tiempo va a dejar de ser necesario de la forma en la que los conoces ahora. Por ejemplo los faxes irán por IP (o sea que ya no necesitas los servicios cifs por ahí)

¿Faxes por IP? Claro, eso el lo que busco, pero necesito centralizarlo todo en un equipo, y sin cups/samba no hay envío de faxes en red que valga desde clientes mixtos.

y lo de las impresoras PDF, ¿te refieres a la conversión de docs bien office u openoffice a pdf? Si es por eso, tanto windows como linux como Mac lo hacen ya out-of-the-box ...

No, me refiero a una solución centralizada: los clientes no tienen más que configurar una impresora PDF (que está en el servidor) para poder generar archivos planos (para archivado) sin necesidad de tener que instalar en cada equipo una solución de software para poder generar documentos pdf desde cualquier aplicación. 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 2009-10-26 a las 13:55 +0100, carlopmart escribió:

Camaleón wrote:

...

...

...

¿Cómo se comparte una impresora de faxes o de pdf vía NFS? Eso con el tiempo va a dejar de ser necesario de la forma en la que los conoces ahora. Por ejemplo los faxes irán por IP (o sea que ya no necesitas los servicios cifs por ahí) ¿Faxes por IP? Claro, eso el lo que busco, pero necesito centralizarlo todo en un equipo, y sin cups/samba no hay envío de faxes en red que valga desde clientes mixtos.

¿Y estás seguro/a de que eso no existe ya sin necesidad de usar un servidor?? Quiero decir, hablo de un funcionamiento parecido a las impresoras IP ...

Muy atrasaditos van entonces los fabricantes de estos cacherrejos ....

Sí, sí, existen. También tengo que administrar uno de esos cacharros en la red A O:-) (es una de esas copiadoras modernas que llevan de todo, por llevar llevan hasta LDAP y disco duro de 40 GB.). Pero el personal no lo usa, utilizan Hylafax, y sólo saltan a ese equipo cuando un fax se le atraganta al ghostscript de la suse, es decir, casi nunca. En el equipo con hylafax tengo más control sobre todo el proceso del archivador, recepción y visualización de faxes que con el equipo multifunción, tiempos de envío y recepción...

...

...

y lo de las impresoras PDF, ¿te refieres a la conversión de docs bien office u openoffice a pdf? Si es por eso, tanto windows como linux como Mac lo hacen ya out-of-the-box ...

...

No, me refiero a una solución centralizada: los clientes no tienen más que configurar una impresora PDF (que está en el servidor) para poder generar archivos planos (para archivado) sin necesidad de tener que instalar en cada equipo una solución de software para poder generar documentos pdf desde cualquier aplicación. Saludos,

Hombre, eso yo creo que con los equipos que hay hoy en día y el software deja de tener sentido. Por ejemplo, con Office 2007 te viene una utilidad que hace eso, la instalas y listo. El usuario después que ubique el archivo donde toca ¿no?.

No, qué va, para nada. Empezando por el precio (el Office "no" es gratis, el openoffice sí :-P) y terminando porque hay que instalar una aplicación de esas en cada equipo. Otra ventaja de la impresora virtual de pdf es que se puede usar desde cualquier aplicación mientras que la del OOo sólo está disponible para documentos que abras con el OOo :-/ Además del control que tienes sobre los archivos. Muchos usuarios me piden "recuperar ese docuemnto en pdf que generaron el día tal o cual" y que obviamente no guardan en sus equipos. Pero los que usan la impresora virtual, como lo tengo configurado para que los archivos se almacenen en un directorio compartido, además de enviar una copia por correo electrónico a cada usaurio de manera individual, pues pueden acceder a los archivos que han generado. En fin, que ambas cosas (impresora de fax y pdf) aún tiene su uso, y mucho :-) 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 2009-10-26 a las 15:12 +0100, carlopmart escribió:

Camaleón wrote:

...

No, qué va, para nada. Empezando por el precio (el Office "no" es gratis, el openoffice sí :-P) y terminando porque hay que instalar una aplicación de esas en cada equipo. Otra ventaja de la impresora virtual de pdf es que se puede usar desde cualquier aplicación mientras que la del OOo sólo está disponible para documentos que abras con el OOo :-/ Además del control que tienes sobre los archivos. Muchos usuarios me piden "recuperar ese docuemnto en pdf que generaron el día tal o cual" y que obviamente no guardan en sus equipos. Pero los que usan la impresora virtual, como lo tengo configurado para que los archivos se almacenen en un directorio compartido, además de enviar una copia por correo electrónico a cada usaurio de manera individual, pues pueden acceder a los archivos que han generado. En fin, que ambas cosas (impresora de fax y pdf) aún tiene su uso, y mucho :-)

Pues entonces no te discuto nada, ya que no trabajo con el entorno usuario desde hace mucho mucho tiempo, cosa que mi psique ha agradecido y mucho :))

:-) No hay nada que me haría más feliz que poder "deshacerme" de samba pero por cosas como estas (fax y pdf en red) no puedo, al menos mientras no tenga un sustituto que me permita obtener la misma flexibilidad que tengo ahora. 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 2009-10-26 a las 11:13 -0500, Jaime Velez escribió:

El Lunes, 26 de Octubre de 2009, Camaleón escribió:

...

En los switches no veo ninguna opción para activar los "jumbo frames" (el campo de velocidad está en "auto", las opciones son:

100m full, 100m half, 10mb full, 10mb half, auto, disable

lo de los jumboframes es para switches de 1000 mbps

Son switches de 24 puertos gigabit (todos los puertos son de 1G) :-? 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

Buenos días, he encontrado algo curioso en: http://www.microsoft.com/spain/interop/resources/SFU35Intro.mspx Resulta que SFU/SUA además de contar con un servidor/cliente para NFS tambien incorpora un GATEWAY para NFS: Gateway para NFS El Gateway para NFS permite el acceso a exports NFS sin necesidad de instalar software adicional en clientes Windows de bajo nivel. Lo hace actuando como pasarela entre la red Windows y la red UNIX (NFS). El Gateway para NFS monta exports NFS y los expone en la red como recursos compartidos de Windows. Los sistemas Windows de la red acceden a los exports NFS de forma indirecta utilizando los protocolos habituales de compartición de archivos de Windows, puesto que ven los exports NFS como si fuesen carpetas compartidas en el Gateway (que es un servidor Windows). Lamentablemente en su día el pc venia con winxp home y es lo que tengo, ni puedo ni quiero comprar otra de winxp... pero he leído en algún foro que el cliente de las utilidades lo han conseguido hacer funcionar en home... investigaré un poco más. Saludos :) -- "El cielo es para los dragones lo que el agua es para las ninfas" -- 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 2009-10-27 a las 11:16 +0100, carlopmart escribió:

David Moreno wrote:

...

Buenos días, he encontrado algo curioso en:

...

http://www.microsoft.com/spain/interop/resources/SFU35Intro.mspx Resulta que SFU/SUA además de contar con un servidor/cliente para NFS tambien incorpora un GATEWAY para NFS:

...

Gateway para NFS El Gateway para NFS permite el acceso a exports NFS sin necesidad de instalar software adicional en clientes Windows de bajo nivel. Lo hace actuando como pasarela entre la red Windows y la red UNIX (NFS). El Gateway para NFS monta exports NFS y los expone en la red como recursos compartidos de Windows. Los sistemas Windows de la red acceden a los exports NFS de forma indirecta utilizando los protocolos habituales de compartición de archivos de Windows, puesto que ven los exports NFS como si fuesen carpetas compartidas en el Gateway (que es un servidor Windows).

...

Lamentablemente en su día el pc venia con winxp home y es lo que tengo, ni puedo ni quiero comprar otra de winxp... pero he leído en algún foro que el cliente de las utilidades lo han conseguido hacer funcionar en home... investigaré un poco más.

Yo no lo haría forastero :)). En serio, no intentes "inventos" de esos ... Es preferible que uses un Windows 2003/2008 o similiar si puedes, olvidate del XP Home. El XP Home es muy muy problemático ... y no querrás que tu madre no pueda ver las fotos, verdad?? :))

Haz caso del consejo de carlopmart. "Más vale malo conocido que bueno por conocer". Y samba es malo... pero no tanto. No puedes luchar contra todo, a veces hay que "plegarse" como hace el sauce llorón, y esperar tiempos mejores :-) 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

David Moreno wrote:

El 27/10/09, Camaleón escribió:

...

Haz caso del consejo de carlopmart.

"Más vale malo conocido que bueno por conocer".

Y samba es malo... pero no tanto.

No puedes luchar contra todo, a veces hay que "plegarse" como hace el sauce llorón, y esperar tiempos mejores :-)

Saludos,

-- Camaleón -- Vamos, imagínate a mi madre teclado en mano diciendo que donde diantres están las fotos.... solo de pensarlo se me ponen los pelos de punta.

Buscando información sofre NFS he encontrado otro protocolo de almacenamiento de datos sobre TCP/IP, iSCSI

http://es.wikipedia.org/wiki/Internet_SCSI

Parece ser compatible con todas las versiones de xp. ¿Seria una opción valida? Gracias :)

iSCSI no comparte archivos. Es un sistema de almacenamiento, sigues necesitando un filesystem y un protocolo de servidor para poder ver los archivos almacenados por los distintos SO. Saludos -- CL Martinez carlopmart {at} gmail {d0t} 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 27/10/09, carlopmart escribió:

iSCSI no comparte archivos. Es un sistema de almacenamiento, sigues necesitando un filesystem y un protocolo de servidor para poder ver los archivos almacenados por los distintos SO.

Saludos

-- CL Martinez carlopmart {at} gmail {d0t} com --

Samba :) Saludos. -- "El cielo es para los dragones lo que el agua es para las ninfas" -- 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

On Tuesday 27 October 2009 12:18:14 carlopmart wrote:

David Moreno wrote:

...

El 27/10/09, Camaleón escribió:

...

Haz caso del consejo de carlopmart.

"Más vale malo conocido que bueno por conocer".

Y samba es malo... pero no tanto.

No puedes luchar contra todo, a veces hay que "plegarse" como hace el sauce llorón, y esperar tiempos mejores :-)

Saludos,

-- Camaleón --

Vamos, imagínate a mi madre teclado en mano diciendo que donde diantres están las fotos.... solo de pensarlo se me ponen los pelos de punta.

Buscando información sofre NFS he encontrado otro protocolo de almacenamiento de datos sobre TCP/IP, iSCSI

http://es.wikipedia.org/wiki/Internet_SCSI

Parece ser compatible con todas las versiones de xp. ¿Seria una opción valida? Gracias

:)

iSCSI no comparte archivos. Es un sistema de almacenamiento, sigues necesitando un filesystem y un protocolo de servidor para poder ver los archivos almacenados por los distintos SO.

algo asi como internet SCSI Es tener los discos duros fuera del servidor y en vez de unirlos a este por el cable SCSI o el SATA (tambien hay algo de iSATA) se unen por un cable ethernet, es el 'barato' de fibre chanel http://es.wikipedia.org/wiki/Internet_SCSI http://es.wikipedia.org/wiki/Canal_de_fibra -- 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 27/10/09, Rafa Griman escribió:

On Monday 26 October 2009 16:16:22 Camaleón wrote:

...

...

Activa jumbo frames en servidor y cliente. Comprueba que el switch soporta jumbo. Las ventajas de jumbo es que el MTU es de 9000 y sin ellos es de 1500. Es decir, hay que gestionar menor # de paquetes por lo que la CPU tiene que trabajar menos y mejoras el rendimiento.

En los switches no veo ninguna opción para activar los "jumbo frames" (el campo de velocidad está en "auto", las opciones son:

100m full, 100m half, 10mb full, 10mb half, auto, disable

Parece que el switch no es gigabit ethernet.

Juvar... que sí lo son >:-) Los puertos que están en "auto" se conectan a 1 GB (los que son enlaces de 1 GB.) y a 100 MB los que son enlaces a 100 MB. Lo que no veo por ningún lado es la configuración de los jumbo frames.

...

...

En cuanto a potencia de CPU. Gbit consume lo suyo (especialmente si no son jumbo frames) y recuerda que Samba lanza un proceso hijo por cada cliente conectado más el proceso padre -> mucha CPU y mucha RAM.

Bueno, aquí no creo que tenga problemas. Los servidores montan dos xeones físicos (4 núcleos), que aunque son antiguos (inicio del año 2.006) aún pueden llevar bien la carga de trabajo. Tienen 8 GB. de ram.

Va bien cargado ;)

...

...

¿Sólo tienes 1 t. red en el servidor? Dependiendo del # de clientes, puede ser interesante tener channel bonding. Teóricamente 1 cliente con 1 puerto Gbit te satura el 1 Gbit del servidor. Si quieres una red balanceada, necesitas el mismo número de puertos de entrada que de salida y que el backplane del switch lo soporte, de lo contrario tienes una interconexión de tipo blocking y el rendimiento no es el máximo (óptimo).

Tengo los dos adaptadores de red configurados en bonding (failover).

Failover es como tener 1 solo puerto, no vas a conseguir mejor rendimiento.

En este caso me interesa una configuración de seguridad más que de rendimiento. No se puede tener todo ¿o sí? O:-)

...

...

Luego el almacenamiento también influye. Si no tienes discos rápidos, ... El cuello de botella lo tienes allí.

Esto sí puede ser un pelín "handicap". Porque no sólo el volumen compartido está en raid5 (controladora raid) sino que los discos son sata 150 :-/

Mal rollo ...

Sí, eso sí :-( Y la controladora raid no es para tirar cohetes, que digamos :-((

...

...

Sinceramente, si no es una cosa desesperante, yo lo que cambiaría/miraría es lo de los jumbo. Pero recuerda que con que un equipo no lo soporte, se te va todo al garete.

En esta red las copias funcionan mucho mejor. El cableado gigabit se nota y los servidores que hay detrás, también :-)

Es que el hardware importa más de lo que la gente se piensa ... y más hoy en día que no se depura ;)

Sip :-)

...

...

...

En la red B tengo clientes suse y windows. Los windows mantienen el mismo esquema que la red A, pero las copias se eternizan (la red es 10/100 y el servidor donde tengo samba no es tan potente). Aquí los clientes suse usan mediante fish:// (gráfico) o ssh (línea de comandos) para transferir las copias en "tar.gz", muy sencillo.

Red lenta y servidor pequeñajo ... mal rollo :(

Por eso comentaba que samba es "lento".

Pero el que el hardware sea pequeño no es culpa de Samba ;)

Cierto :-P Pero es lo que hay en gran parte de las oficinas. Y en casa, pues peor :-(

...

Si se tiene una red bien puesta o un enlace directo (equipo a equipo) y son equipos medianamente potentes, pase. Pero no siempre es así y cuando tienes que hacer una copia de archivos grandes (imagen iso 4.7 GB o copias de seguridad), se nota :-(

Si a eso le añades la configuración de los usuarios y los permisos para los recursos en samba, pues se hace un poco "pesado".

Sip.

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 :) On Tuesday 27 October 2009 23:57:23 Camaleón wrote:

El 27/10/09, Rafa Griman escribi�:

...

On Monday 26 October 2009 16:16:22 Camale�n wrote:

...

...

Activa jumbo frames en servidor y cliente. Comprueba que el switch soporta jumbo. Las ventajas de jumbo es que el MTU es de 9000 y sin ellos es de 1500. Es decir, hay que gestionar menor # de paquetes por lo que la CPU tiene que trabajar menos y mejoras el rendimiento.

En los switches no veo ninguna opci�n para activar los "jumbo frames" (el campo de velocidad est� en "auto", las opciones son:

100m full, 100m half, 10mb full, 10mb half, auto, disable

Parece que el switch no es gigabit ethernet.

Juvar... que s� lo son >:-)

OK, aceptamos barco ;)

Los puertos que est�n en "auto" se conectan a 1 GB (los que son enlaces de 1 GB.) y a 100 MB los que son enlaces a 100 MB.

Lo que no veo por ning�n lado es la configuraci�n de los jumbo frames.

En los switches que yo he visto no hay que configurar nada. En la documentación te debería poner si lo soportan o no. Generalmente/vulgarmente se llaman jumbo frames, pero tenían otro nombre, pero no me acuerdo cuál 0:) [...]

...

...

Tengo los dos adaptadores de red configurados en bonding (failover).

Failover es como tener 1 solo puerto, no vas a conseguir mejor rendimiento.

En este caso me interesa una configuraci�n de seguridad m�s que de rendimiento. No se puede tener todo �o s�? O:-)

Si no recuerdo mal, hay un modo de channel bonding que te hace las dos cosas, pero no estpy seguro.

...

...

...

Luego el almacenamiento tambi�n influye. Si no tienes discos r�pidos, ... El cuello de botella lo tienes all�.

Esto s� puede ser un pel�n "handicap". Porque no s�lo el volumen compartido est� en raid5 (controladora raid) sino que los discos son sata 150 :-/

Mal rollo ...

S�, eso s� :-(

Y la controladora raid no es para tirar cohetes, que digamos :-((

[...]

...

Es que el hardware importa m�s de lo que la gente se piensa ... y m�s hoy en d�a que no se depura ;)

Sip :-)

[...] Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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 2009-10-26 a las 13:07 +0100, Rafa Griman escribió: ...

Samba es muy pesado de configurar (especialemnte si tienes un AD o servidores PDC) y encima, no hace reconexiones si pierdes el servidor. Es decir, si tienes dos Samba en HA y uno cae, el otro no retoma la conexión del cliente sino que el cliente tiene que reconectar (volver a hacer doble click). En el caso de NFS, se balancea esa conexión abierta por lo que el cliente no se entera que se ha caido el servidor. Hasta donde yo sé, esto es una limitación del protocolo/estándar SMB/CIFS.

Ah....! En el curro tenemos una base de datos en red, no estoy seguro de si usa "sybase" o directorios en red compartidos (windows), o una combinación, y si lleva mucho tiempo encendido y se cae la red, hay que reiniciar el programa. Ridículo. Lo que dices lo explicaría. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkrngZMACgkQtTMYHG2NR9VDpgCfQKTN50BBDPE5UVaG5nU/RZz1 X3gAn17biU19YB52g0F6I97oW2ljwYAm =cwpR -----END PGP SIGNATURE-----

Hola :) On Wednesday 28 October 2009 00:15:40 Camaleón wrote:

El 27/10/09, Rafa Griman escribió:

...

On Tuesday 27 October 2009 12:27:20 Camaleón wrote:

[...]

...

Huys, mira que he visto eso del iscsi por suse (en yast aparece un módulo para gestionarlo) y no sé qué es. Leyendo la wikipedia no me queda del todo claro el concepto (¿una SAN?) ni los requerimientos cliente/servidor/infraestructura necesaria.

A ver si alguien nos puede dar más datos, pero así a simple vista lo veo muy ennfocado a la empresa :-?

iSCSI te permite compartir un dispositivo de bloques mediante una red ethernet. Generalmente, los servidores se conecta[ba]n a una cabina de discos mediante SCSI, FC o SAS. Como eso es muy caro, salió uno e inventó el iSCSI.

Con el iSCSI no haces más que conectar el servidor con una cabina de discos mediante ethernet, de forma que es más barato. Como todo en esta vida, tiene ventajas e inconvenientes:

- no hay que confundirlo con un protocolo de servidor de ficheros como FTP, CIFS, NFS, ...

- no da el rendimiento que da un SAS, SCSI o FC

- si no separas la red iSCSI de la corporativa (e-mail, web, ...) ... el rendimiento cae aún más porque metes más tráfico en la red

- al presentar un dispositivo de bloques, puedes poner un sistema de ficheros en cluster encima (OCFSv2, GFS) y todas las máquinas pueden trabajar con un único sistema de ficheros como si fuera un DAS o una SAN. Esto es teórico ya que si el sistema de ficheros en cluster no soporta iSCSI ... mejor no usarlo ;)

En cuanto a que Linux (openSUSE u otras distros) soporten iSCSI o muestren la opción de configurar iSCSI, lo que significa es que puedes, desde tu distro, exportar una partición de disco (sda5, por ejemplo) como si tu PC/servidor/WS fuera una cabina iSCSI y emular una cabina iSCSI o emular una SAN.

Gracias :-)

En la wikipedia menciona que iSCSI es como una SAN, y una SAN es una forma de compartir un disco duro a través de la red ¿no? :-?

SAN (Storage Area Network) es básicamente una cabina de discos conectada a más de un servidor/WS. La conexión puede ser iSCSI, FC, SAS, SCSI. Aquí no hay protocolo de red, se ven dispositivos de bloque únicamente. Al compartir con varios servidores/WS, se pueden dar dos alternativas: - todos o algunos de los servidores comparten partición por lo que tienes dos alternativas: * sistema de ficheros en cluster (CXFS, GFS, OCFSv2, VeritasFS...) * HA activo/pasivo - ninguno comparte partición por lo que tienes que particionar la cabina y cada servidor/ws ve su propia partición y no puede acceder a las otras particiones/datos. En la SAN, no hay filesystem (lo decides tu) ni protocolo de red, es un dispositivo de bloques puro y duro. Es como si fuera un disco interno de tu PC/WS/servidor, pero en vez de estar dentro, lo tienes fuera, en una cabina. En la SAN, los servidores/WS no "saben" que hay más gente conectada, se creen que tienen la exclusividad de los discos. DAS (Direct Attached Storage) es una cabina de discos conectada a un servidor/WS. En etse caso NO hay protocolo para compartir ficheros, el servidor/WS ve la cabina de discos como si fueran discos internos suyos y sólo suyos. Además, no hay nadie más conectado a la cabina de discos, sólo hay un servidor/WS/PC. NAS es un almacenamiento conectado por red eth a una serie de servidores que usan un protocolo de red (NFS, SMB/CIFS, FTP, ...) para acceder a los discos. En etse caso hay un protocolo para compartir ficheros. En este caso y ahay filesystem y permisos y protocolos de red y todo ese rollo. Los PCs/WS/servidores "saben" que comparten almacenamineto y que no es suyo en exclusiva.

Otra cosa, ¿qué tipo de discos admite? ¿De todo tipo (sas, sata, scsi, fc)? Como se llama iSCSI, despista... O:-)

Lo que de tu bolsillo ;) Lo de iSCSI significa que son comandos SCSI a través de protocolo IP. Vamos que en vez de usar cables SCSI usan cables Eth, pero lo que se "habla" es iSCSI (encapsulado y todo eso). Luego ha salido FCoE que es Fibre Channel por red Ethernet. No le veo la gracia porque la latencia en Eth es muy superior a la de FC "de toda la vida". De todas maneras, si no las latencias no son críticas, iSCSI es una solución SAN barata, pero no es equiparable en rendimiento a una SAN basada en SAS o FC. Es decir, iSCSI no te va a dar mejor rendimiento que Samba ;) Además, te sale "más caro" que Samba ya que necesitas montar un clustered filesystem si quieres que todos vean el mismo almacenamiento. HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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 2009-10-28 a las 10:26 +0100, Rafa Grimán escribió:

On Wednesday 28 October 2009 00:15:40 Camaleón wrote:

...

...

En cuanto a que Linux (openSUSE u otras distros) soporten iSCSI o muestren la opción de configurar iSCSI, lo que significa es que puedes, desde tu distro, exportar una partición de disco (sda5, por ejemplo) como si tu PC/servidor/WS fuera una cabina iSCSI y emular una cabina iSCSI o emular una SAN.

Gracias :-)

En la wikipedia menciona que iSCSI es como una SAN, y una SAN es una forma de compartir un disco duro a través de la red ¿no? :-?

SAN (Storage Area Network) es básicamente una cabina de discos conectada a más de un servidor/WS. La conexión puede ser iSCSI, FC, SAS, SCSI. Aquí no hay protocolo de red, se ven dispositivos de bloque únicamente. Al compartir con varios servidores/WS, se pueden dar dos alternativas:

- todos o algunos de los servidores comparten partición por lo que tienes dos alternativas: * sistema de ficheros en cluster (CXFS, GFS, OCFSv2, VeritasFS...) * HA activo/pasivo

- ninguno comparte partición por lo que tienes que particionar la cabina y cada servidor/ws ve su propia partición y no puede acceder a las otras particiones/datos.

En la SAN, no hay filesystem (lo decides tu) ni protocolo de red, es un dispositivo de bloques puro y duro. Es como si fuera un disco interno de tu PC/WS/servidor, pero en vez de estar dentro, lo tienes fuera, en una cabina.

En la SAN, los servidores/WS no "saben" que hay más gente conectada, se creen que tienen la exclusividad de los discos.

Hum... sí, tengo un SAN chiquitín (de Netgear) con dos discos ata/ide al que sólo pueden acceder los equipos que tienen instalado un driver "especial" para poder a los discos (horrible, tengo que buscarle un reemplazo cuanto antes). Netgear SC101 http://en.wikipedia.org/wiki/Sc101 Ya entiendo... entonces un SAN necesita siempre una cabina de conexión, no puedes crear un SAN desde los discos conectados a la placa base y compartirlo mediante la red ¿no? Buf...

DAS (Direct Attached Storage) es una cabina de discos conectada a un servidor/WS. En etse caso NO hay protocolo para compartir ficheros, el servidor/WS ve la cabina de discos como si fueran discos internos suyos y sólo suyos. Además, no hay nadie más conectado a la cabina de discos, sólo hay un servidor/WS/PC.

NAS es un almacenamiento conectado por red eth a una serie de servidores que usan un protocolo de red (NFS, SMB/CIFS, FTP, ...) para acceder a los discos. En etse caso hay un protocolo para compartir ficheros. En este caso y ahay filesystem y permisos y protocolos de red y todo ese rollo. Los PCs/WS/servidores "saben" que comparten almacenamineto y que no es suyo en exclusiva.

No le veo mucha ventaja al san al das respecto al nas, salvo para aligerar la carga/trabajo de los servidores o para ampliar espacio "rápidamente" :-?. Una solución nas parece mucho más flexible. Gracias... estas son las cosas que la wikipeda no siempre aclara :-)

...

Otra cosa, ¿qué tipo de discos admite? ¿De todo tipo (sas, sata, scsi, fc)? Como se llama iSCSI, despista... O:-)

Lo que de tu bolsillo ;) Lo de iSCSI significa que son comandos SCSI a través de protocolo IP. Vamos que en vez de usar cables SCSI usan cables Eth, pero lo que se "habla" es iSCSI (encapsulado y todo eso).

Luego ha salido FCoE que es Fibre Channel por red Ethernet. No le veo la gracia porque la latencia en Eth es muy superior a la de FC "de toda la vida".

De todas maneras, si no las latencias no son críticas, iSCSI es una solución SAN barata, pero no es equiparable en rendimiento a una SAN basada en SAS o FC. Es decir, iSCSI no te va a dar mejor rendimiento que Samba ;) Además, te sale "más caro" que Samba ya que necesitas montar un clustered filesystem si quieres que todos vean el mismo almacenamiento.

Aclarado. Danke :-) 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 :) On Wednesday 28 October 2009 11:44:18 Camaleón wrote:

El 2009-10-28 a las 10:26 +0100, Rafa Grimán escribió:

...

On Wednesday 28 October 2009 00:15:40 Camaleón wrote:

...

...

En cuanto a que Linux (openSUSE u otras distros) soporten iSCSI o muestren la opción de configurar iSCSI, lo que significa es que puedes, desde tu distro, exportar una partición de disco (sda5, por ejemplo) como si tu PC/servidor/WS fuera una cabina iSCSI y emular una cabina iSCSI o emular una SAN.

Gracias :-)

En la wikipedia menciona que iSCSI es como una SAN, y una SAN es una forma de compartir un disco duro a través de la red ¿no? :-?

SAN (Storage Area Network) es básicamente una cabina de discos conectada a más de un servidor/WS. La conexión puede ser iSCSI, FC, SAS, SCSI. Aquí no hay protocolo de red, se ven dispositivos de bloque únicamente. Al compartir con varios servidores/WS, se pueden dar dos alternativas:

- todos o algunos de los servidores comparten partición por lo que tienes dos alternativas: * sistema de ficheros en cluster (CXFS, GFS, OCFSv2, VeritasFS...) * HA activo/pasivo

- ninguno comparte partición por lo que tienes que particionar la cabina y cada servidor/ws ve su propia partición y no puede acceder a las otras particiones/datos.

En la SAN, no hay filesystem (lo decides tu) ni protocolo de red, es un dispositivo de bloques puro y duro. Es como si fuera un disco interno de tu PC/WS/servidor, pero en vez de estar dentro, lo tienes fuera, en una cabina.

En la SAN, los servidores/WS no "saben" que hay más gente conectada, se creen que tienen la exclusividad de los discos.

Hum... sí, tengo un SAN chiquitín (de Netgear) con dos discos ata/ide al que sólo pueden acceder los equipos que tienen instalado un driver "especial" para poder a los discos (horrible, tengo que buscarle un reemplazo cuanto antes).

Netgear SC101 http://en.wikipedia.org/wiki/Sc101

Ya entiendo... entonces un SAN necesita siempre una cabina de conexión, no puedes crear un SAN desde los discos conectados a la placa base y compartirlo mediante la red ¿no? Buf...

Sí puedes, usas Linux y montas iSCSI para exportar esos discos vía eth. El cliente iSCSI verá esos discos exportados como discos duros locales. Lo que tienes que tener cuidado es que: - si conectas más de un equipo a la misma partición, tendrás que usar un clustered filesystem - si conectas cada partición a un único equipo, podrás usar el filesystem que quieras

...

DAS (Direct Attached Storage) es una cabina de discos conectada a un servidor/WS. En etse caso NO hay protocolo para compartir ficheros, el servidor/WS ve la cabina de discos como si fueran discos internos suyos y sólo suyos. Además, no hay nadie más conectado a la cabina de discos, sólo hay un servidor/WS/PC.

NAS es un almacenamiento conectado por red eth a una serie de servidores que usan un protocolo de red (NFS, SMB/CIFS, FTP, ...) para acceder a los discos. En etse caso hay un protocolo para compartir ficheros. En este caso y ahay filesystem y permisos y protocolos de red y todo ese rollo. Los PCs/WS/servidores "saben" que comparten almacenamineto y que no es suyo en exclusiva.

No le veo mucha ventaja al san al das respecto al nas, salvo para aligerar la carga/trabajo de los servidores o para ampliar espacio "rápidamente" :-?. Una solución nas parece mucho más flexible.

La ventaja de la SAN es realmente por temas de latencia y anchos de banda. Una red SAN basada en SAS o FC te da unos 8 Gbit/s por cable si es FC (teóricos) o unos 12 Gbit/s por cable si es SAS (teóricos también). Cada cable SAS puede ofrecer hasta 12 Gbit/s y cada cable FC puede ofrecer 8 Gbit/s siempre y cuando: - tengas una HBA que dé ese rendimiento - tengas suficientes discos para dar ese rendimiento - tengas controladoras en la cabina que den ese rendimiento - los drivers funcionen bien Conseguir los anchos de banda estos es fácil si compras buen hardware. Generalmente usas más de un cable y tienes controladoras redundadas por lo que el ancho de banda es muy superior a esos 8 Gbit/s ó 12 Gbit/s. Además de eso, puedes tener unas latencias muy bajas por lo que las SAN (basadas en FC o SAS) son muy buenas para: - BBDD - edición de vídeo en tiempo real - postproducción - HPC científico - CAD/CAM/CAE - HPC financiero - LAN free backup SAN basada en iSCSI no es bueno para estas cosas. En cambio con una NAS, para conseguir esos anchos de banda ... necesitas poner un servidor muy grande. Por ejemplo, nosotros a un cliente le estamos dando 6.4 GBytes/s desde una cabina de discos (FC 8 Gbit/s, 2 controladoras, ...). Si pretendes dar 6.4 Gbytes/s mediante Samba/CIFS, NFS y/o FTP ... tienes que montar un bicho muy grande, sólo en puertos 1 Gbit Eth ibas a tene que poner 54 puertos GigE (suponiendo que realmente sacas 120 MBytes de cada puerto) o bien 6 tarjetas 10 GigE. No sólo eso, si además quieres latencias bajas para editar vídeo ... mal vamos. Esto no significa que una SAN sea mejor que una NAS, depende de lo que quieres hacer, el presupuesto, infraestructuras que tienes, ...

Gracias... estas son las cosas que la wikipeda no siempre aclara :-)

:)

...

...

Otra cosa, ¿qué tipo de discos admite? ¿De todo tipo (sas, sata, scsi, fc)? Como se llama iSCSI, despista... O:-)

Lo que de tu bolsillo ;) Lo de iSCSI significa que son comandos SCSI a través de protocolo IP. Vamos que en vez de usar cables SCSI usan cables Eth, pero lo que se "habla" es iSCSI (encapsulado y todo eso).

Luego ha salido FCoE que es Fibre Channel por red Ethernet. No le veo la gracia porque la latencia en Eth es muy superior a la de FC "de toda la vida".

De todas maneras, si no las latencias no son críticas, iSCSI es una solución SAN barata, pero no es equiparable en rendimiento a una SAN basada en SAS o FC. Es decir, iSCSI no te va a dar mejor rendimiento que Samba ;) Además, te sale "más caro" que Samba ya que necesitas montar un clustered filesystem si quieres que todos vean el mismo almacenamiento.

Aclarado. Danke :-)

Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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

On Wednesday 28 October 2009 15:09:34 Rafa Griman wrote:

Hola :)

On Wednesday 28 October 2009 11:44:18 Camaleón wrote:

...

El 2009-10-28 a las 10:26 +0100, Rafa Grimán escribió:

...

On Wednesday 28 October 2009 00:15:40 Camaleón wrote:

...

...

En cuanto a que Linux (openSUSE u otras distros) soporten iSCSI o muestren la opción de configurar iSCSI, lo que significa es que puedes, desde tu distro, exportar una partición de disco (sda5, por ejemplo) como si tu PC/servidor/WS fuera una cabina iSCSI y emular una cabina iSCSI o emular una SAN.

Gracias :-)

En la wikipedia menciona que iSCSI es como una SAN, y una SAN es una forma de compartir un disco duro a través de la red ¿no? :-?

SAN (Storage Area Network) es básicamente una cabina de discos conectada a más de un servidor/WS. La conexión puede ser iSCSI, FC, SAS, SCSI. Aquí no hay protocolo de red, se ven dispositivos de bloque únicamente. Al compartir con varios servidores/WS, se pueden dar dos alternativas:

- todos o algunos de los servidores comparten partición por lo que tienes dos alternativas: * sistema de ficheros en cluster (CXFS, GFS, OCFSv2, VeritasFS...) * HA activo/pasivo

- ninguno comparte partición por lo que tienes que particionar la cabina y cada servidor/ws ve su propia partición y no puede acceder a las otras particiones/datos.

En la SAN, no hay filesystem (lo decides tu) ni protocolo de red, es un dispositivo de bloques puro y duro. Es como si fuera un disco interno de tu PC/WS/servidor, pero en vez de estar dentro, lo tienes fuera, en una cabina.

En la SAN, los servidores/WS no "saben" que hay más gente conectada, se creen que tienen la exclusividad de los discos.

Hum... sí, tengo un SAN chiquitín (de Netgear) con dos discos ata/ide al que sólo pueden acceder los equipos que tienen instalado un driver "especial" para poder a los discos (horrible, tengo que buscarle un reemplazo cuanto antes).

Netgear SC101 http://en.wikipedia.org/wiki/Sc101

Ya entiendo... entonces un SAN necesita siempre una cabina de conexión, no puedes crear un SAN desde los discos conectados a la placa base y compartirlo mediante la red ¿no? Buf...

Sí puedes, usas Linux y montas iSCSI para exportar esos discos vía eth. El cliente iSCSI verá esos discos exportados como discos duros locales. Lo que tienes que tener cuidado es que:

- si conectas más de un equipo a la misma partición, tendrás que usar un clustered filesystem

- si conectas cada partición a un único equipo, podrás usar el filesystem que quieras

...

...

DAS (Direct Attached Storage) es una cabina de discos conectada a un servidor/WS. En etse caso NO hay protocolo para compartir ficheros, el servidor/WS ve la cabina de discos como si fueran discos internos suyos y sólo suyos. Además, no hay nadie más conectado a la cabina de discos, sólo hay un servidor/WS/PC.

NAS es un almacenamiento conectado por red eth a una serie de servidores que usan un protocolo de red (NFS, SMB/CIFS, FTP, ...) para acceder a los discos. En etse caso hay un protocolo para compartir ficheros. En este caso y ahay filesystem y permisos y protocolos de red y todo ese rollo. Los PCs/WS/servidores "saben" que comparten almacenamineto y que no es suyo en exclusiva.

No le veo mucha ventaja al san al das respecto al nas, salvo para aligerar la carga/trabajo de los servidores o para ampliar espacio "rápidamente" :-?. Una solución nas parece mucho más flexible.

La ventaja de la SAN es realmente por temas de latencia y anchos de banda. Una red SAN basada en SAS o FC te da unos 8 Gbit/s por cable si es FC (teóricos) o unos 12 Gbit/s por cable si es SAS (teóricos también).

Cada cable SAS puede ofrecer hasta 12 Gbit/s y cada cable FC puede ofrecer 8 Gbit/s siempre y cuando: - tengas una HBA que dé ese rendimiento - tengas suficientes discos para dar ese rendimiento - tengas controladoras en la cabina que den ese rendimiento - los drivers funcionen bien

Conseguir los anchos de banda estos es fácil si compras buen hardware. Generalmente usas más de un cable y tienes controladoras redundadas por lo que el ancho de banda es muy superior a esos 8 Gbit/s ó 12 Gbit/s. Además de eso, puedes tener unas latencias muy bajas por lo que las SAN (basadas en FC o SAS) son muy buenas para:

- BBDD - edición de vídeo en tiempo real - postproducción - HPC científico - CAD/CAM/CAE - HPC financiero - LAN free backup

SAN basada en iSCSI no es bueno para estas cosas.

En cambio con una NAS, para conseguir esos anchos de banda ... necesitas poner un servidor muy grande. Por ejemplo, nosotros a un cliente le estamos dando 6.4 GBytes/s desde una cabina de discos (FC 8 Gbit/s, 2 controladoras, ...). Si pretendes dar 6.4 Gbytes/s mediante Samba/CIFS, NFS y/o FTP ... tienes que montar un bicho muy grande, sólo en puertos 1 Gbit Eth ibas a tene que poner 54 puertos GigE (suponiendo que realmente sacas 120 MBytes de cada puerto) o bien 6 tarjetas 10 GigE. No sólo eso, si además quieres latencias bajas para editar vídeo ... mal vamos.

Esto no significa que una SAN sea mejor que una NAS, depende de lo que quieres hacer, el presupuesto, infraestructuras que tienes, ...

...

Gracias... estas son las cosas que la wikipeda no siempre aclara :-)

:) :

...

...

...

Otra cosa, ¿qué tipo de discos admite? ¿De todo tipo (sas, sata, scsi, fc)? Como se llama iSCSI, despista... O:-)

Lo que de tu bolsillo ;) Lo de iSCSI significa que son comandos SCSI a través de protocolo IP. Vamos que en vez de usar cables SCSI usan cables Eth, pero lo que se "habla" es iSCSI (encapsulado y todo eso).

Luego ha salido FCoE que es Fibre Channel por red Ethernet. No le veo la gracia porque la latencia en Eth es muy superior a la de FC "de toda la vida".

De todas maneras, si no las latencias no son críticas, iSCSI es una solución SAN barata, pero no es equiparable en rendimiento a una SAN basada en SAS o FC. Es decir, iSCSI no te va a dar mejor rendimiento que Samba ;) Además, te sale "más caro" que Samba ya que necesitas montar un clustered filesystem si quieres que todos vean el mismo almacenamiento.

Aclarado. Danke :-)

Rafa

-- "We cannot treat computers as Humans. Computers need love."

rgriman@skype.com rgriman@jabberes.org

Happily using KDE 4.3.1 :)

js -- Saludos Lluis

Hola, ante todo queria agradecer a Rafa su explicación de las tecnologias iScsi, NAS, SAN y como funcionan en los "Bichos grandes". El 28/10/09, Rafa Griman escribió:

Hola :)

Sí puedes, usas Linux y montas iSCSI para exportar esos discos vía eth. El cliente iSCSI verá esos discos exportados como discos duros locales. Lo que tienes que tener cuidado es que:

- si conectas más de un equipo a la misma partición, tendrás que usar un clustered filesystem

- si conectas cada partición a un único equipo, podrás usar el filesystem que quieras

Entonces, si no lo he entendido mal, el compartir un disco mediante el protocolo de red iSCSI es como si el disco estuviera conectado físicamente a la computadora cliente, del mismo modo que no puedes conectar un disco duro a dos ordenadores mediante el mismo cable. Para hacer esto debes utilizar un "clustered filesystem". Lo que he encontrado en google sobre esta "palabreja" son referencias a Solaris y RedHat. [...]

:)

Rafa

-- "We cannot treat computers as Humans. Computers need love."

rgriman@skype.com rgriman@jabberes.org

Happily using KDE 4.3.1 :)

El 28/10/09, Juan Erbes escribió:

Algo como esto quieres armar?: http://news.bbc.co.uk/2/hi/technology/6584075.stm

http://www.amd.com/us/press-releases/Pages/Press_Release_84919.aspx

http://www.studiodaily.com/filmandvideo/technique/how/ILM-Builds-the-Bots-fo...

http://www.awn.com/articles/profiles/escalating-vfx-new-itransformersi

Salu2

Pues no tengo tanta plata, aunque me voy a pedir uno de esos "Monstruos" para mi cumple.... a ver si cae Saludos :) -- "El cielo es para los dragones lo que el agua es para las ninfas" -- 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/10/09, csalinux escribió:

Tenemos suerte de contar con el biólogo segoviano linuxero Rafa Grimán que aparece poco pero cuando aparece siempre nos enseña algo... (Con él SuSE era SuSE y era bastante mejor distro :) ).

Y con Camaleón también, ?eh? no se nos vaya a enfadar que esta chica anda siempre al quite por aquí. :)

--

Saludos.

César

Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado.

(Proverbio hindú)

He aprendido muchísimo de ambos desde que leo esta lista, además siempre escriben de forma correcta y educada. Como diría mi madre son dos rosales como dos soles de grandes. Por cierto no sabia que Rafa es Biólogo, pensaba que era catedrático informático, por lo menos. Aunque la biología molecular y la bioquímica están íntimamente ligadas a la informática. :) Saludos -- "El cielo es para los dragones lo que el agua es para las ninfas" -- 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/10/09, csalinux escribió:

Sí, se hacen cálculos teóricos Tom-CLOA "ab initio", y semi empíricos... pero no creo que en sus "tiempos" se usara linux pa eso... (en los míos no, un poquito de unix, pero era todo mayormente en Güindows. (Yo lo poco que aprendí a programar fue empezando un doctorado en Química cuántica con orbitales gaussianos -qué potitos los espacios Hilbert-, qué tiempos aquellos, me tocaba las narices y no tenía ninguna responsabilidad :) ).

...

:)

Saludos

--

Saludos.

César

Enfréntate a los malos; enfréntate a los crueles; enfréntate a todos, menos a los tontos. Son demasiados y siempre serás derrotado.

(Proverbio hindú)

Pues entonces debo ser un privilegiado, en mi facultad, publica, trabajábamos con apple y disponíamos de un montón de software para cálculos de los que no conocíamos ni la mitad, hasta que avanzas en la carrera, trayectorias orbitales, distancias moleculares.... recuerdo el chemmol y alguno más. Incluso los apuntes eran virtuales. La metódica CLOA Hummm! que recuerdos.... Sin preocupaciones hipotecarias. Aunque solo volvería atrás si puedo conservar todo lo conozco a día de hoy, el presente tampoco esta mal... Por cierto César, ¿Tu conoces algo de clustered filesystem? me estoy volviendo loco gogleando y todo se refiere a SUN, ORACLE y "grandes bichos"... :) Saludos -- "El cielo es para los dragones lo que el agua es para las ninfas" -- 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 :) On Thursday 29 October 2009 11:34:08 csalinux wrote:

David Moreno escribi�:

...

Hola, ante todo queria agradecer a Rafa su explicaci�n de las tecnologias iScsi, NAS, SAN y como funcionan en los "Bichos grandes".

El 28/10/09, Rafa Griman escribi�:

...

Hola :)

S� puedes, usas Linux y montas iSCSI para exportar esos discos v�a eth. El cliente iSCSI ver� esos discos exportados como discos duros locales. Lo que tienes que tener cuidado es que:

- si conectas m�s de un equipo a la misma partici�n, tendr�s que usar un clustered filesystem

- si conectas cada partici�n a un �nico equipo, podr�s usar el filesystem que quieras

Entonces, si no lo he entendido mal, el compartir un disco mediante el protocolo de red iSCSI es como si el disco estuviera conectado f�sicamente a la computadora cliente, del mismo modo que no puedes conectar un disco duro a dos ordenadores mediante el mismo cable. Para hacer esto debes utilizar un "clustered filesystem". Lo que he encontrado en google sobre esta "palabreja" son referencias a Solaris y RedHat.

[...]

...

:)

Rafa

-- "We cannot treat computers as Humans. Computers need love."

rgriman@skype.com rgriman@jabberes.org

Happily using KDE 4.3.1 :)

El 28/10/09, Juan Erbes escribi�:

...

Algo como esto quieres armar?: http://news.bbc.co.uk/2/hi/technology/6584075.stm

http://www.amd.com/us/press-releases/Pages/Press_Release_84919.aspx

http://www.studiodaily.com/filmandvideo/technique/how/ILM-Builds-the-Bot s-for-IMAX-Shots-in-Transformers-Sequel_11019.html

http://www.awn.com/articles/profiles/escalating-vfx-new-itransformersi

Salu2

Pues no tengo tanta plata, aunque me voy a pedir uno de esos "Monstruos" para mi cumple.... a ver si cae

Saludos

:)

Tenemos suerte de contar con el bi�logo segoviano linuxero Rafa Grim�n que aparece poco pero cuando aparece siempre nos ense�a algo... (Con �l SuSE era SuSE y era bastante mejor distro :) ).

Se agradece (¿cómo se pone un smiley ruborizado?). ¡ Qué tiempos cuando uno era joven ! ...

Y con Camale�n tambi�n, ?eh? no se nos vaya a enfadar que esta chica anda siempre al quite por aqu�. :)

Aquí hay mucha gente con buenos conocimientos: Carlos, Juan, Lluis, César, ... También es cierto que Camaleon es la que más genio tiene ;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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 :) On Thursday 29 October 2009 13:13:32 David Moreno wrote:

El 29/10/09, csalinux escribi�:

...

S�, se hacen c�lculos te�ricos Tom-CLOA "ab initio", y semi emp�ricos... pero no creo que en sus "tiempos" se usara linux pa eso... (en los m�os no, un poquito de unix, pero era todo mayormente en G�indows. (Yo lo poco que aprend� a programar fue empezando un doctorado en Qu�mica cu�ntica con orbitales gaussianos -qu� potitos los espacios Hilbert-, qu� tiempos aquellos, me tocaba las narices y no ten�a ninguna responsabilidad :) ).

[...]

Pues entonces debo ser un privilegiado, en mi facultad, publica, trabaj�bamos con apple y dispon�amos de un mont�n de software para c�lculos de los que no conoc�amos ni la mitad, hasta que avanzas en la carrera, trayectorias orbitales, distancias moleculares.... recuerdo el chemmol y alguno m�s. Incluso los apuntes eran virtuales. La met�dica CLOA Hummm! que recuerdos.... Sin preocupaciones hipotecarias. Aunque solo volver�a atr�s si puedo conservar todo lo conozco a d�a de hoy, el presente tampoco esta mal...

x"D

Por cierto C�sar, �Tu conoces algo de clustered filesystem? me estoy volviendo loco gogleando y todo se refiere a SUN, ORACLE y "grandes bichos"...

Ojo que este tema trae confusión: ¿clustered filesystem? O bien, ¿parallel filesystem? Te lo digo porque no es lo mismo. Ejemplos: - clustered filesystem: CXFS, GFS, OCFSv2 - parallel filesystem: Lustre, GPFS, pNFS El clustered filesystem es para una SAN. Permite que muchos PCs/WS/servidores se conecten al mismo filesystem y piensen que es suyo. Recordemos que en la SAN no hay protocolo de red sino un mero filesystem. Lo que conseguimos con esto es que todos trabajen contra los mismos datos (a veces al mismo tiempo) y que no se dupliquen los datos. Esto generalmente se usa para pocos PCs/WS/servidores y lo que importa es la latencia y el ancho de banda (a veces usado para tiempo real). Casos típicos de uso: - media: postproducción, NLEs, ... - HPC: ingenierías o proyectos en los que varios WS/PCs trabajan sobre los mismos datos - BBDD: una única BBDD con servidores de BBDD trabajando en paralelo (BBDD en cluster) El parallel filesystem, en cambio, es una NAS. Bueno, realmente son varias NAS, con varias cabinas de almacenamiento y los datos se encuentran "rotos" y distribuidos por los diferentes almacenamientos. Cada almacenamiento tiene una porción del fichero. Recordemos que aquí _SÍ_ hay un protocolo de red y un filesystem. En este caso, se busca que todos trabajen sobre los mismos datos, pero hay cientos o miles de clientes conectados simultáneamente y además lo que importa es que haya un elevado ancho de banda (la latencia no es necesaria), hablamos de 30, 40, 50 GBytes/s (_NO_ Gbit/s). Los parallel filesystems son muy típicos en entornos científicos e ingenierías. Lustre es el más conocido y usado (es software libre ;) Aunque, si algún día se ponen de acuerdo, posiblemente pNFS "se lleve el gato al agua". ¿Para qué lo quieres usar? ¿Cuál es el entorno de trabajo? HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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 2009-10-31 a las 13:37 +0100, Rafa Grimán escribió: (...)

El otro día estaba hablando con un amigo de Segovia que hace cortos y postproducción y algo de 3D y estábamos hablando de lo complicado que es hacer cosas como:

- que al botar una pelota, haya realismo: cuántos botes, cómo se deforma al tocar el suelo, altitud del bote, ... Incluso cuando hacen el modelado y todo el 3D, luego retocan (GIMP, cineGIMP, Photoshop, ...) los fotogramas del render porque siempre queda algo.

- refracción y reflexión de los rayos de luz al poner un vidrio, un plástico, agua, ... delante de un objeto

Ni que lo digas. Tuve que tocar un par de años el 3DMax y... tela marinera. Las versiones actuales me parece que ya tienen más módulos para obtener unos resultados realistas con la física. Antes, ese tipo de efectos se se tenían que conseguir con una mezcla de texturas y el "ray tracing", pero ambos estaban en pañales, y los resultados (tras horas de renederizado) eran... bueno, eran muy malos X-) La evolución de la industria del 3D se ha ido viendo en los largometrajes de animación (Toy Story, Antz... Mostruos SA, etc...). La diferencia entre las primeras películas y las más actuales es abismal :-)

También estuve hablando hace poco con un cliente que se dedica a hacer puentes. Por mucho que simulen, siempre hay un tipo que tiene que ir a medir y "tocar" porque no se llega a un nivel de realismo suficiente, siempre falta algo. Aquí Camaleón tiene algo que decir, si no me equivoco. No sé si son puentes lo que hacen, pero algo de ingeniería civil me suena que hacen en su trabajo.

Ingenería industrial, más que nada, pero también arquitectura civil, sí :-) Aquí el realismo no parece que importe demasiado, los cálculos estructurales son los que mandan y no hay tu tía, quede "bonito" o no. Para las presentaciones y memorias pues ya los "ponen de gala" (con renderizados "efectistas" -y yo diría que casi "surrealistas-), y se consiguen resultados bastante buenos, la verdad. 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 día 31 de octubre de 2009 09:09, Rafa Griman escribió:

Hola :)

On Saturday 31 October 2009 13:52:13 Camaleón wrote:

...

El 2009-10-31 a las 13:20 +0100, Rafa Grimán escribió:

...

On Thursday 29 October 2009 11:34:08 csalinux wrote:

...

Tenemos suerte de contar con el bi�logo segoviano linuxero Rafa Grim�n que aparece poco pero cuando aparece siempre nos ense�a algo... (Con �l SuSE era SuSE y era bastante mejor distro :) ).

Se agradece (¿cómo se pone un smiley ruborizado?). ¡ Qué tiempos cuando uno era joven ! ...

Enlazas a alguna imagen que muestre el estado :-P

http://www.fotosearch.com/bthumb/CSP/CSP120/k1205479.jpg

Buena idea ;)

...

...

...

Y con Camale�n tambi�n, ?eh? no se nos vaya a enfadar que esta chica anda siempre al quite por aqu�. :)

(este correo se me pasó >:-?)

¡¡Ehh!!

...

Aquí hay mucha gente con buenos conocimientos: Carlos, Juan, Lluis, César, ... También es cierto que Camaleon es la que más genio tiene ;)

:-)

¡¡Ehhh "2"!! Grrr...

Sobre todo gruño cuando me acuerdo del kde 4.0.x en su etapa inicial }:-)

x"D

  Rafa

-- "We cannot treat computers as Humans. Computers need love."

rgriman@skype.com rgriman@jabberes.org

Happily using KDE 4.3.1 :) -- 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 a todos(as), Sería realmente un crimen desperdiciar el conocimiento compartido de tanto experto(a) en SuSE! Yo provengo de RedHat/Centos y al instalar openSuSE en mi laptop personal, "vi la luz" :-D Estoy a sus órdenes, desde Lima, Perú. Saludos, -- Francisco Neira Usuario Linux # 165985 Miembro # 565432 ISACA Lima, Peru -05:00 GMT -- 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 :) On Sunday 01 November 2009 12:53:06 Camaleón wrote:

El 2009-10-28 a las 12:03 +0100, Camaleón escribió:

...

El 2009-10-28 a las 10:51 +0100, Rafa Grimán escribió:

...

...

Ahora es buen momento para hacer cambios de este tipo porque me toca actualizar los servidores.

Actualizar servidores: mola. Pide cosas chulas :)

Sólo cambia el SO, los hierros siguen igual :-P

...

Los modos que permiten ambas cosas son: balance-tlb or 5 balance-alb or 6

Creo que me ha funcionado mejor el 5 que el 6, pero es muy sencillo de cambiar: - paras red - cambias el 5 por el 6 (o al revés) - reinicias red - pruebas - si no te gusta, vuelves al paso 1 y lo dejas como estaba ;)

Bueno, al menos esto sí podré probarlo.

Ya contaré como lo dejo al final, supongo que con el modo 5, salvo que los swicthes estos se "atraganten" con tanto flujo >:-)

Ayer estuve "migrando" uno de los servidores y aproveché para activar este modo (bonding en modo 5). Todo bien :-)

Al hacer la prueba de rigor (lo que hago es ejecutar "ping -c 100 google.es" y desconectar primero uno de los cables -eth0-, comprobar que sigue enviando paquetes y desconectar el otro enlace de red -eth1- para ver que sigue igual.

Durante el "ping" se veía cómo caía un enlace y se activaba el otro, eso es correcto, pero al pararlo (ctrl+c) me decía que había habido una pérdida del 1% de los paquetes... ¿es eso normal? :-?

Hombre, al ser un ping, no me preocupa. Prueba con ficheros grandes de los tuyos y haces un sum o lo que sea qu euses para comprobar que origen y destino son iguales. Nosotros no hemos tenido pérdida ni corrupción de datos. En TCP ten en cuenta que si se pierde un paquete, lo vuelve a pedir el destino al origen así que no deberías perder paquetes. Si quieres monitorizarlo de manera muy interesante, prueba a usar saidar como herramienta de monitorización (software.opensuse.org/search). Es una herramienta (CLI) que me encanta ya que monitoriza en tiempo real todo y, en el caso del bonding, te monitoriza el bond y cada puerto independientemente. HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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 :) On Monday 02 November 2009 10:56:18 David Moreno wrote:

El 31/10/09, Rafa Griman escribi�:

...

Ojo que este tema trae confusi�n: �clustered filesystem? O bien, �parallel filesystem?

Te lo digo porque no es lo mismo. Ejemplos: - clustered filesystem: CXFS, GFS, OCFSv2 - parallel filesystem: Lustre, GPFS, pNFS

El clustered filesystem es para una SAN. Permite que muchos PCs/WS/servidores se conecten al mismo filesystem y piensen que es suyo. Recordemos que en la SAN no hay protocolo de red sino un mero filesystem. Lo que conseguimos con esto es que todos trabajen contra los mismos datos (a veces al mismo tiempo) y que no se dupliquen los datos. Esto generalmente se usa para pocos PCs/WS/servidores y lo que importa es la latencia y el ancho de banda (a veces usado para tiempo real). Casos t�picos de uso:

- media: postproducci�n, NLEs, ...

- HPC: ingenier�as o proyectos en los que varios WS/PCs trabajan sobre los mismos datos

- BBDD: una �nica BBDD con servidores de BBDD trabajando en paralelo (BBDD en cluster)

El parallel filesystem, en cambio, es una NAS. Bueno, realmente son varias NAS, con varias cabinas de almacenamiento y los datos se encuentran "rotos" y distribuidos por los diferentes almacenamientos. Cada almacenamiento tiene una porci�n del fichero. Recordemos que aqu� _S�_ hay un protocolo de red y un filesystem. En este caso, se busca que todos trabajen sobre los mismos datos, pero hay cientos o miles de clientes conectados simult�neamente y adem�s lo que importa es que haya un elevado ancho de banda (la latencia no es necesaria), hablamos de 30, 40, 50 GBytes/s (_NO_ Gbit/s).

Los parallel filesystems son muy t�picos en entornos cient�ficos e ingenier�as. Lustre es el m�s conocido y usado (es software libre ;) Aunque, si alg�n d�a se ponen de acuerdo, posiblemente pNFS "se lleve el gato al agua".

�Para qu� lo quieres usar? �Cu�l es el entorno de trabajo?

Pues un entorno dom�stico, quiero montar un peque�o servidor de ficheros en donde almacenar datos, fotos y copias de seguridad de los pc�s de la familia... Puede que mas de un pc acceda (lectura) a los mismos datos (ver una foto) pero no hay escritura simult�nea sobre el mismo fichero, me ha interesado el sistema iSCSI por eso investigo m�s sobre el tema, el hardware de que dispongo te lo pongo abajo y dinero tengo m�s bien poco ;)

Si es para entorno casero, yo no dudaría en poner Samba o NFS. Porque no es un entorno qu enecesite grandes rendimientos (a menos que os dediquéis a editar vídeo, HPC, ...). En todo caso, si lo que quieres es mejorar el rendimiento, tienes varias soluciones: - poner Gigabit Ethernet y activar Jumbo frames - poner varias t. red 10/100 y hacer bonding - poner varios discos duros y una buena controladora - todas las opciones anteriores - alguna de las opciones anteriores

El 23/10/09, David Moreno escribi�:

...

Se conectarian menos de 4 clientes, trabajar�amos con dos tipos de datos: Ficheros peque�os de menos de 10 MB para los documentos y ficheros de de mas de 1GB para las copias de seguridad. Dispongo de un disco de sistema y 4 discos (actualmente vac�os) para un RAID 5 en el que almacenar la informaci�n. Ademas dispongo de un disco externo para copias de seguridad adicionales.

Samba o NFS te sirven de sobra para lo que quieres hacer. iSCSI y su correspondiente clustered filesystem te van a consumir mucho tiempo y no vas a conseguir mejora alguna (es más, tendrás más problemas ya que no son fáciles de montar). Samba y NFS permiten que dos usuarios vean el mismo fichero al mismo tiempo, aunque no lo pueden modificar al mismo tiempo, pero para el número de usuairos que tienes, te sobra. Si metes GigE, recuerda lo siguiente: - no haría falta que todos los clientes fueran GigE porque es una red pequeña - si sólo tienes gigE en el servidor, no actives jumbo frames - si todo es GigE, recuerda que el cableado debe ser Cat 5e o Cat 6. Si es Cat 5, asegúrate que todos los pares de cobre estén conectados (hay algunos fabricantes que no los conectan porque 10/100 no los usan)

El 23/10/09, David Moreno escribi�:

...

2GB de ram ddr2 AMD Atlon X2 a 2 Ghz. 4 Discos de 80 GB 2 SATA 2 IDE Los discos son id�nticos dos a dos.

El cuello de botella lo vas a tener en los discos ya que vas a montar RIAD 5 y tienes dos discos SATA y 2 IDE. La máxima velocidad que obtendrás es la de los discos IDE. Teniendo en cuenta el tamaño de la red (4 PCs) y el uso que se le va a dar, no creo que lo notes. Resumiendo, yo pondría: - Samba o NFS - 2 t. de red 10/100 en bonding a menos que ya tengas una GigE - quizás ampliarái a 4 GB de RAM (opcional, depende del precio) Lo demás es complicarse la vida porque no necesitas tanto rendimiento. HTH Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.1 :) -- 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