Mailinglist Archive: opensuse-es (614 mails)

< Previous Next >
Re: [opensuse-es] Re: lvm o particiones extendidas
  • From: Rafa Grimán <rafagriman@xxxxxxxxx>
  • Date: Fri, 23 Apr 2010 11:10:23 +0200
  • Message-id: <201004231110.23878.rafagriman@xxxxxxxxx>
Hola :)

On Friday 23 April 2010 10:13 Camaleón wrote
El Fri, 23 Apr 2010 00:25:06 +0200, Rafa Grimán escribió:
On Thursday 22 April 2010 17:53 Carlos E. R. wrote

(...)

Siempre y cuando la política de la empresa te deje. Pueden exigirte
tener en linea varios gigas de espacio para cada usuario en imap, en
plan gmail.

El acrhivado puede está shelved cuando lo sacas de la librería o del
jukebox de CD/DVD/BR. Sacar cintas de una librería para backup es
bastante normal (hay que evitar que backup y datos estén físicamente
próximos). El archivado (a cinta o a CD/DVD/BR) no significa
necesarioamente que te lo llevas a otra oficina, a un banco, a un vault
o similar, significa que no lo tienes en disco principal. Es decir,
puede estar dentro de la librería de cintas.

Rafa, ¿de verdad crees que los correos que tienen los usuarios en Gmail
están archivados en cintas y almacenados allá en Mountain View? >:-)


Te sorprendería saber lo que hay en cinta y el usuario cree que está en disco.
Te pongo un ejemplo que es mucho más "delicado": NBA. Está haciendo streaming
en Internet de todos sus videos y creeme, la gran mayoría están en cinta. Es
cliente nuestro ;)

Otra cosa, no confundas cosas. Yo no he dicho que tenga que estar TODO en
cinta, he dicho cosas como (copio y pego):

"2.- como admin, estableces reglas de migración que auto-
máticamente t emigran los correos más antiguos"

"Los ficheros más usados, se encuentran en los discos SAS, los menos
usados en SATA y los que están llenos de polvo en cinta."

"Nada es eterno ;) Los datos/correos tarde o temprano se vuelven
antiguos
y se pueden archivar."


Es decir, lo que se archiva o lo que se migra (en el caso de HSM) son datos
antiguos. Obviamente, los correos de ayer y de hoy no se migran. ¿Quién define
lo que es antiguo? Como siempre, el jefe ;) Como Admin, debes opinar y
presentar un estudio de uso del correo (o cualquier otro dato). Yo, como
fabricante o integrador no te puedo decir cada cuánto tienes que migrar o
archivar los datos, ATEMPO tampoco, IBM tampoco, EMC tampoco, ... Eso lo
tienes que establecer tu como admin de tu empresa.

Como integrador y fabricnate lo que sí es hecho es ayudar al cliente y
asesorarle y formarle en el uso de la herramienta de forma que si quiere
cambiar sus políticas, lo pueda hacer sin mi. De hecho, los 3 - 4 primeros
meses la gente se queja y andas experimentando hasta que consigues afinar las
reglas. Pero una vez que tienes las reglas "en su sitio", la cosa funciona.

Claro está que puedes contratar a una empresa para que te haga ese estudio ...
pero vas a tener que pagar la consultoría (y el SW que quieran instalar para
monitorizar el comportamiento de los usuarios y el flujo de trabajo).

También es cierto que tus políticas no le valen a Google ni a la gestoría de
la esquina ni a la NBA, cada caso es un mundo. Por eso, lo tienen que decidir
el cliente final.

En cuanto a Google, creeme, lo tienen todo muy bien estudiado y no me
extrañaría que tuvieran en cinta mucha más info de la que creemos ;) No sólo
Google sino otros como FaceBook o NYSE o cualquier otro grande.


También hay que tener en cuenta un tipo de archivado "especial" que es
lo que se llama copia legal y es básicamente lo que exige la ley en
cuanto a determinados datos digitales: que tienes que tener una copia
para revisiones legales durante no sé cuánto tiempo. Se tiene que
guardar en un medio inalterable (WORM) y tienes que garantizar su
lectura durante ese tiempo que exige la ley.

Sí, pero es que no hablamos de "archivar". Archivar implica dar un
tratamiento especial a los datos, sacarlos de su ubicación actual y
moverlos a otro espacio (físico o lógico) por lo que dejan de estar
accesibles en tiempo real para el servidor o el usuario.


Volvemos a lo de antes, se supone que has hecho un estudio sobre qué datos y
cuándo se pueden migrar porque no hace falta tiempo real. Este es el caso de
correo-e, documentos ofimáticos, imágenes, ...

En el caso de audio y/o vídeo que sí puedes necesitar tiempo real (el
streaming de YouTube, por ejemplo, no es tiempo real ni lo es ningún streaming
basado en Flash), lo que se hace es lo que he comentado en un correo anterior
(copio y pego):

" - dejar los primeros segundos en el nivel 1 y el resto
migrarlo

- migrar ciertas partes, por ejemplo, del minuto 1 al 7,
del 8 al 9 los mirga a nivel 2 dejando el resto de minutos
en nivel 1.

Así, cuando el usuario pida el fichero de vídeo, no tiene que esperar
sino que lo vé inmediatamente y cree que está todo on-line."


El /var puede ser muy grande. Aunque lo gestiones bien, lo repartas, lo
archives en tres capas, puede ser enorme. Es a donde van los datos que
no son propiedad de un usuario sino de todos, es decir, los datos que
se "sirven" desde el servidor.

/var es para ficheros de tamao variable, de ahí el nombre.

Un "tamaño variable" requiere un "espacio variable" y esos datos pueden e
estar ahí meses o años antes de pasar a ser archivados >:-)


Efectivamente y esa variación de tamaño luego se refleja en la cantidad
"variable" de dinero que quieras pagar:
- disco -> más caro + más consumo + más calor
- cinta -> más barato + menos consumo + menos calor

Oye, por mi encantado que NO quieras archivar y ójala todos los clientes
pensaran así -> vendería más disco y me haría rico. Pero la realidad es otra:

"¿por qué pagar más por mantener un dato on-line cuando NO
es necesario que esté on-ĺine?"

Y creeme, que si el jefe y el de contabilidad/compras/financiero oyen "pagar
más" o "pagar menos" ... la cosa cambia.


Pero vuelvo a lo de antes, sí: jerárquicamente /var crece y,
jerárquicamente / crece
también, pero eso es desde un punto de vista lógico, NO físico ;) Si nos
ponemos a mirarlo desde un punto de vista físico (que es el que interesa
porque los discos son elementos físicos y no lógicos) lo que crece es el
sistema de ficheros y /var /var/cache (por ejemplo) pueden ser dos
sistemas de ficheros diferentes luego físicamente, el que crece es
/var/cache, pero no /var ;) Lo mismo va para /var/log o /var/mail o
/var/lo_que_quieras, si lo diseñas bien, lo diseñarás como sistemas de
ficheros diferentes.

Si tienes un disco pequeño, "/var" ni se parte ni se divide. No compensa,
al contrario, te penaliza.


Si tienes un disco físico pequeño en *nix, hacerlo crecer es muy sencillo:
compras un disco nuevo y lo montas bajo /var/disco_nuevo ;)


Es decir, si hay un directorio "caótico" ese es "/var" (puede aumentar su
tamaño o disminuirlo de forma aleatoria y sin un patrón concreto).


Por eso mismo existen:
- gestores de volúmenes
- sw de HSM
- sw de archivado
- dedupe


Imagina un correo enorme que tenga que estar en la cola dirigido a todos
los usuarios del sistema enviado con malas intenciones,


Para eso se establecen límites en el tamaño del correo, entre otros límites ;)
Si no estableces límites: mal hecho.

Ya, ya sé que el usuario se queja si le pones límites. Tuve un amigo
trabajando en "Infobirria" y le llamo un lciente indignado porque "el correo
no funciona". El cliente quería enviar una imagen iso por correo. Sí, quería
envíar los 670 MBytes de un CD a un colega. Pues qué quieres que te diga ...
que se queje todo lo que quiera, hay unos límites en el correo y en las
autopistas y en la tarjeta de crédito y en lo que puedes comer/beber de una
sentada y en todo en esta vida.


e imagina además
que por política de empresa todos los mensajes enviados/recibidos se
duplican en una cuenta de seguridad... aumentas el espacio requerido en "/
var" de manera exponencial en apenas unos segundos.


Tu lo has dicho: es una COPIA, luego no es necesaria on-line porque tienes el
original on-line. Es un ejemplo de lo que en un correo anterior llamaba (o
llaman algunos clientes/empresas) copia legal.

Esa copia puede estar perfectamente en una librería de cintas, bien sea con o
sin VTL por en medio para darle mayor agilidad/velocidad al proceso o se hace
todas las noches o la política que creas conveniente, pero es lo que tu misma
has dicho: una copia.


¿Y cuándo se eliminan
los correos pesados? Pues dependerá de cada usuario. Algunos lo
descargaran vía pop, otros lo mantendrán accesible vía imap... y otros no
lo bajarán en ¿meses?.


Pero ahí ya interviene la política de empresa. si la empresa dice que se hace
así, así y así. Pues es como hay que hacerlo. Los recursos son de la empresa,
nos guste o no y es la empresa la que establece las normas. Obviamente, si tu
como Admin le consigues explicar bien las cosas al jefe ... se harán "bien".

Si tu, como Admin, rechazas una tecnología porque sí ... a lo mejor te estás
perdiendo una cosa que te ahorraría mucha pasta y que podrías invertir en
cosas que necesitas: formación, renovación de equipos, ...


O el mismo "zypper" te puede disparar las necesidades de espacio actuales
en "/var" al generar archivos de registro de actividad de "no-sé-cuantos"
gigas por un error.


Ahí hay otra tecnología que se llama thin provisioning u oversubscription.
También hay una cosa que se llama previsión, como Admin tienes que preveer la
cantidad de un recurso que vas a necesitar. Obviamente es IMPOSIBLE acertar
con las predicciones, pero tienes una idea.

En HPC (sea científico, media, financiero, ...) el volumen de datos que se
maneja es algo inhumano y las previsiones a 3 años sabes a ciencia cierta que
el 1er año te las vas a fundir, peor aún así ... se hacen estimaciones y
previsiones para no quedarte de pronto sin espacio.

¿Qué ocurre cuando esta gente se queda de pronto sin espacio? Muy sencillo:
1.- monitorizan todo mucho para que esto casi no ocurra
2. -tienen SW de archivado
3.- tienen SW de HSM
4.- tienen SW de dedupe
5.- tienen políticas a medida en función de sus flujos de trabajo
Siendo el 5 punto el más importante.

Ya sé que me vas a decir que tu no manejas sus presupuestos, pero no tiene
nada que ver porque su presupuesto es 500% mayor que el tuyo, pero sus
necesidades son 5000% mayores que las tuyas por lo que salen ellos perdiendo
;)

Además de eso, piensa que:

- a lo mejor tu no necesitas HSM: ya te has quitado un gasto que
ellos sí tienen

- a lo mejor tu puedes funcionar perfectamente con un sw de
backup* FLOSS: te has ahorrado las licencias que ellos tienen
que pagar porque no hay soluciones FLOSS que les valga

* o cualquier otro sw que tu no licencias y ellos sí: servidores de ficheros,
servidor de correo, ...

Te vuelvo a repetir: no te estoy inentando convencer de que uses o no una
tecnología (sea de gestión de almacenamiento, como es este caso) o sea de
monitorización de cámaras IP. Yo te comento lo que hay, lo que se usa, en qué
casos, ... que a ti te guste o no, que te convenzca, que te parezca bueno o
no, ... Oye, ya es cosa tuya: yo sólo intento ayudar porque he visto que en
casos similares ... sí ha funcionado ;)

Rafa

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

Happily using KDE 4.4.1 :)
--
Para dar de baja la suscripción, mande un mensaje a:
opensuse-es+unsubscribe@xxxxxxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
opensuse-es+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups