Re: [ot] soluciones "caseras" de almacenaje SAN/NAS
El vie, 03-02-2012 a las 15:34 -0500, jorarome escribió:
> Por casualidad este hilo a sido oportuno, ya que casualmente ando en
> un rollo parecido. Trato de mejorar unas bases de datos MySQL y Oracle
> y queden con ALta Disponibilidad HA, la plataforma en la que operan es
> Debian y son para diversasaplicaciones web de una institucion
> educativa mediana., y al ir inspeccionando las diferentes fuentes
> encontradas se vislumbra soluciones como Clustes de BD, virtualizacion
> y redes SAN, NAS, y esto me a sunido en una confusion total, muchas
> referencias encontras se enfocan con la utilizacion de DRBD. La
> institucion cuenta con hardware Discos RAID5, en la cuales se
> almancena lo respectivo a los datos que se manejan con Oracle.Estare
> atento a como se desenvuelte este hilo estoy seguro de que algun tip
> tecnico, consejos que pueda sacarme de este estancamiento. De antemano
> les agrdezco por tanto conocimeinto que se aporta a la lista.
>
>
Deberías haber abierto otro hilo.
El gran problema de los Cluster de HA es el almacenamiento compartido,
de mi experiencia te puedo decir:
DRBD no es usable (por lento) mas que en casos donde haya poco trafico
de disco, su unica ventaja es que con solo dos equipos puedes montar un
cluster HA (no necesita de otro para el almacenamiento).
Si el cluster es Activo/Activo estas obligado a usar un filesistem de
cluster que es difícil de montar (ocfs gfs veritas ...) si solo quieres
HA y te conformas con un Activo/Pasivo no tendrás estos problemas, te
basta con montar el disco remoto en la maquina que este activa y
desmontarlo de la no activa.
El tipo de infraestructura vendrá dado por las necesidades de
rendimiento y las disponibilidad de dinero, con estos criterios el
orden seria:
HBA (conexión de fibra) NAS
iSCSi NAS
NFS SAN
smb SAN
DRBD
Se que hay otros protocolos pero no los he probado y creo que no
cambiaran mucho los criterios.
--
Por favor, NO utilice formatos de archivo propietarios para el
intercambio de documentos, como DOC y XLS, sino HTML, RTF, TXT,
CSV o cualquier otro que no obligue a utilizar un programa de un
fabricante concreto para tratar la información contenida en él.
SALUD.
Reply to: