domingo, septiembre 2, 2007, 08:33 PM - GNU/Linux, Apple
Un post rápido: tras buscar por media Internet y no encontrar la solución, si uno quiere tener más de 516 megabytes de RAM en Parallels con Centos5 lo que tiene uno que hacer es poner en el grub.conf el parámetro agp=off. Yo lo tengo ahora con 900 megabytes y va muy bien
[ añadir comentario ] ( 65 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 650 )sábado, junio 2, 2007, 08:09 PM - GNU/Linux, Humor
En el principio Turing creó la Máquina.Y la Máquina era enrevesada y artificiosa, existiendo solamente en
teoría. Y von Neuman miró hacia la Máquina, y vió que era enrevesada.
Él dividió la máquina en dos Abstracciones, el Dato y el Código, y los
dos eran unaa misma Arquitectura. Este es un gran Misterio, y el
principio de la sabiduría Y von Neumann habló a la Arquitectura, y la
bendijo diciendo: "Sal y reprodúcete, intercambiando libremente datos
y código, y puebla la tierra con todo tipo de dispositivos. Y así fué
hecho, y era bueno. La Arquitectura prosperó y fué realizada en
hardware y software. Y pobló la tierra con muchos Sistemas.
Los primeros sistemas fueron poderosos gigantes; Muchos y grandes
trabajos de renombre lograron. Entre ellos estaba Colossus, el
rompeclaves, ENIAC, el artillero; EDSAC y MULTIVAC y todo tipo de
criaturas alucinantes cuyo nombre terminaba en AC, los
experimentadores; y SAGE, el defensor del cielo y padre de todas las
redes. Esos eran poderosos gigantes de la antiguedad, las primeras
criaturas de Turing, y sus trabajos han sido escritos en los Libros de
los Ancianos. Esta fué la primera Era, la era de la Sabiduría.
Entonces los hijos de Mercadotecnia se fijaron en los hijos de Turing
y vieron que eran ágiles de mente y limpios de nombre y tenían muchos
atributos grandes y perniciosos. Y se dijeron a sí mismos, "vayamos y
hagamos Corporaciones, y unamos los Sistemas a nuestro propio uso, de
modo que nos traigan gran fortuna". Con dulces palabras sedujeron a
sus clientes, y con muchas cadenas ataron a los Sistemas, para
amoldarlos a su propia imagen. Y los hijos de Mercadotecnia se
vistieron con Conjuntos, los mejores para atraer a sus clientes, y
escribieron Licencias graves y peligrosas, las mejores para atar a los
Sistemas. Y los hijos de Mercadotecnia fueron entonces conocidos como
Conjuntos, despreciando y siendo despreciados por los verdaderos
Ingenieros, los hijos de von Neumann.
Y los Sistemas y sus Corporaciones se replicaron y crecieron numerosos en la tierra. En aquellos días estaban IBM y Digital, Burroughs y Honeywell, Unisys y Rand, y muchos otros. Y cada uno de ellos se mantuvo con su propio Sistema, hardware y software, y no se mezclaron, pues lo prohibían sus Licencias. Esta fué la segunda era, la era de los Mainframes.
Entonces sucedió que los espíritus de Turing y von Neumann miraron
hacia la tierra y se enfadaron. Los Sistemas y sus Corporaciones se
habían hecho grandes y voluminosas, y los Conjuntos habían desplazado
a los verdaderos Ingenieros. Y los clientes lloraron y gimieron
amargamente al cielo, diciendo, "¡Oh, si fuese creado un sistema
poderoso y pequeño, capaz de llegar incluso hasta el hogar!". Y los
Ingenieros lloraron y gimieron igualmente, diciendo "¡ Oh, si surgiera
un proveedor que nos liberase de esos Conjuntos opresivos y sus graves
y peligrosas Licencias, y nos diera un Sistema verdaderamente nuestro,
en el que pudiéramos hacer nuestros inventos y adaptar las cosas a
nuestro gusto!". Y los espíritus de Turing y von Neumann oyeron los
llantos y se dijeron uno al otro: "Descendamos y fabriquemos un
Rompelímites, para que los llantos se calmen"
Y ese día los espíritus de Turing y von Neumann se introdujeron en
Moore, de Intel, proporcionándole la intuición y la sabiduría para
entender el futuro. Y Moore fué uno con el chip y lo produjo, y le
puso de nombre 4004. Y Moore bendijo al chip, diciendo: "Tú eres un
Rompelímites; con mi Corporación te he fabricado. Aunque eres tan
pequeño como una mota de polvo, crecerás y te replicarás hasta el
tamaño de una montaña, y conquistarás a todos los que fueron antes que
tú. Esta es la bendición que te doy: Cada dieciocho meses duplicarás
tu capacidad, hasta el fin de la Era". Esta es la ley de Moore, que
perdura hasta nuestros días.
Y el nacimiento del 4004 fué el principio de la Tercera Era, la era de
los Microchips. Y así como los Mainframes y sus Sistemas y
Corporaciones habían florecido, de ese mismo modo hicieron los
Microchips, y sus Sistemas y Corporaciones. Y su linaje fué el
siguiente:
Moore engendró a Intel. Intel engendró a Mostech, Zilog y Atari.
Mostech engendró a 6502, y Zilog engendró a Z80. Intel también
engendró a 8800, quien engendró a Altair; y 8086, madre de todos los
PCs. 6502 engendró a Commodore, quien engendró a PET y a 64; y Apple,
quien engendró a 2. (Apple es el gran Misterio, la Fruta que fué
devorada, aunque floreció de nuevo.) Atari engendró a 800 y 1200,
maestros del Juego, quienes fueron destruídos por Sega y Nintendo.
Xerox engendró a PARC. Commodore y PARC engendraron a Amiga, creador
de hermosas artes; Apple y PARC engendraron a Lisa, quien engendró a
Macintosh, quien engendró a iMac. Atari y PARC engendraron a ST, el
músico, quien murió y nunca más fué. Z80 engendró a Sinclair el gnomo,
a TRS-80 y a CP/M, quien tuvo muchas máquinas, mas pronto dejó este
mundo. Altair, Apple y Commodore engendraron juntos a Microsoft, la
Gran Oscuridad que es llamada Abominación, Destructor de la Tierra,
las Cancelas del Infierno.
Luego sucedió en la Era de los Microchips
que IBM, la mayor de las Corporaciones de Mainframes, se fijó en los
jóvenes sistemas de Microchips y se sintió gravemente vejada. Y en su
vejación y en su cólera golpearon la tierra y crearon el PC de IBM. El
PC carecía de sonido y color, siendo enrevesado y artificioso en gran
medida, pareciendo un desharrapado, sin embargo, los Clientes fueron
fuertemente inducidos y compraron PCs en gran número. E IBM buscó un
Proveedor de Sistemas Operativos, ya que en su apresuramiento no
habían creado uno, ni habían fraguado una licencia apropiada,
diciendo: "Primero crearemos el mercado, luego crearemos un nuevo
Sistema, uno con nuestra propia imagen, y sujeto por nuestra
Licencia".
Mas ellos razonaron con su orgullo y no con sabiduría, no
previendo la cólera que iba a venir. E IBM se acercó a Microsoft,
quien obtuvo una licencia de QDOS, el hijo de CP/M y 8086. (8086 era
la hija de INTEL, la criatura de Moore). Y QDOS creció, y recibió por
nombre MSDOS. Y MSDOS y el PC juntos crecieron vigorosamente y
conquistaron todos los mercados, replicándose y tomando posesión de
ellos, de acuerdo con la ley de Moore. E Intel creció terriblemente y
devoró a todos sus hijos, de modo que ningún chip podía quedar tras
ella. Y Microsoft creció soberbia, y devoró a IBM, y esto fué una gran
maravilla en la tierra. Todas estas cosas están escritas en los Libros
de los Hechos de Microsoft.
En la plenitud del tiempo, MS-DOS engendró a Windows. Y este es el linaje de Windows: CP/M engendró a QDOS. QDOS
engendró a DOS 1.0. DOS 1.0 engendró a DOS 2.0 por vía de Unix. DOS
2.0 engendró a Windows 3.11 por vía de PARC y Macintosh. IBM y
Microsoft engendraron a OS/2, quien engendró a Windows NT y Warp, el
perdido S.O. de la tradición. Windows 3.11 engendró a Windows 95 tras
triunfar sobre Macintosh en una poderosa batalla de Licencias. Windows
NT engendró a NT 4.0 por vía de Windows 95. NT 4.0 engendró a NT 5.0,
el S.O. también llamado Windows 2000, el Bug del Milenio, Apocalipsis,
Armagedón, El Fin de Todas las Cosas.
Luego vino a suceder que Microsoft había crecido grande y poderosa en
medio de las Corporaciones de Microchips; más poderosa que cualquiera
de las Corporaciones que había antes de que ella creciera. Y el
corazón de Gates se endureció y le juró a sus Clientes e Ingenieros
las palabras de esta maldición:
"Hijos de von Neumann, oídme. IBM y
las Corporaciones de Microchips creadas por nuestros ancestros nos
ataron con graves y peligrosas Licencias, de modo que nosotros
imploramos nuestra liberación a los espíritus de Turing y von Neumann.
Ahora yo os digo: Soy más grande que ninguna Corporación que me haya
precedido. ¿Vais vosotros a perder vuestras Licencias?. Nada de eso,
yo os ataré con Licencias el doble de graves y diez veces más
peligrosas que mis antecesores. Cincelaré mi Licencia en vuestros
corazones y escribiré mi Número de Serie en vuestros lóbulos
frontales. Os ataré a la Plataforma Windows con astutos artificios y
con tortuosos esquemas. Os ataré al chip de Intel con código
enrevesado y retorcidos interfaces. Os capturaré y esclavizaré como
ninguna generación ha sido esclavizada anteriormente. ¿Para qué
implorais a los espíritus de Turing, von Neumann o Moore?. Ellos no os
oyen. Me he convertido en un Poder mayor que ellos. Ahora debéis
rezarme solamente a mí y vivir a merced de mi rabia. Yo soy las
Cancelas del Infierno; Sostengo el portal a MSNBC y las llaves de la
Pantalla Azul de la Muerte. Temedme; temedme intensamente; servidme
sólo a mí y viviréis."
Y la gente fué presa del terror y aclamó a Microsoft, y forzada por el
terror soportó duras y peligrosas pruebas con la plataforma Windows y
su artificiosísima Licencia. Y de nuevo le rogaron a Turing y von
Neumann y Moore que les enviase un salvador, pero nadie fué encontrado
capaz de la tarea hasta el nacimiento de Linux.
Estas son las generaciones de Linux: SAGE engendró a ARPA, quien
engendró a TCP/IP, y Aloha, quien engendró a Ethernet. Bell engendró a
Multics, quien engendró a C, quien engendró a Unix. Unix y TCP/IP
engendraron a Internet, quien engendró a la World Wide Web. Unix
engendró a RMS, padre del gran Ñú GNU, quien engendró las Librerías y
Emacs, jefe de las Utilidades. En los días de la Web, Internet y
Ethernet engendraron la RAL Intranet, cuya rosa le dió renombre entre
todas las Corporaciones y preparó el camino del Pingüino. Y Linus y la
Web engendraron el Kernel a través de Unix. El Kernel, las Librerías y
las Utilidades juntas son la Distribución, el único Pingüino en muchas
formas, por siempre y para siempre alabado.
En esos días sucedió que había un joven escolar en Helsinki que se
llamaba Linus el Torvald. Linus era un hombre devoto, un discípulo de
RMS, fuerte en el espíritu de Turing, von Neumann y Moore. Un día,
meditando en la Arquitectura, Linus cayó en trance y tuvo una visión.
Y en la visión vió un magnífico pingüino, sereno y agraciado, sentado
sobre un témpano de hielo mientras comía pescado. Y ante la vista del
pingüino Linus se asustó profundamente, y rogó a los espíritus de
Turing, von Neumann y Moore para que le ayudasen a interpretar ese
sueño.
Y en el sueño los espíritus de Turing, von Neumann y Moore le
contestaron diciendo: "No temas, Linus, nuestro bienamado hacker. Tú
eres mogollón de guai y alucinante. El gran Pingüino que ves es un
Sistema Operativo que crearás y extenderás por todo el mundo. El
témpano de hielo es la tierra y todos sus sistemas, sobre los que el
Pingüino descansará y se regocijará cuando complete su tarea. Y los
peces de los que se alimenta el Pingüino son los programas con
enrevesadas Licencias, que flotan bajo todos los sistemas de la
tierra. El pingüino cazará y devorará todo lo que es lioso, retorcido
y artificioso; todo el código que se retuerce como el espagetti, o
está infestado de criaturas marchitadoras, o está atado por graves y
peligrosas Licencias deberá capturar. Y en capturarlo deberá
replicarse, y en replicándose deberá documentarse, y en la
documentación deberá dar libertad, serenidad y la mayor maravilla y
alucine a la tierra y todos los que programan en ella".
Linus resurgió de la meditación y creó un pequeño Núcleo de Sistema
Operativo como el sueño le había predicho. A la manera de RMS, publicó
el Núcleo en la Telaraña Mundial para que todos pudieran obtenerlo y
contemplarlo. Y en la plenitud del tiempo de Internet el Núcleo creció
y se replicó, haciéndose más guai y alucinante hasta que al fín fué
reconocido como un Pingüino realmente grande y poderoso, cuyo nombre
era Tux. Y los seguidores de Linux tomaron refugio en el Núcleo, las
Librerías y las Utilidades; instalaron Distribución tras Distribución,
hicieron sacrificios en favor de GNU y el Pingüino, y dieron gracias a
los espíritus de Turing, von Neumann y Moore, por su liberación de las
garras de Microsoft.
Y este fué el principio de la Cuarta Era, la era
del Código Fuente Abierto. Hay mucho más que decir acerca de los
extrañísimos y maravillosos sucesos de aquellos días; cómo algunos
Conjuntos de Microsoft planearon la guerra contra el Pingüino, pero
fueron descubiertos en una víspera de Halloween; cómo Gates cayó entre
abogados y fué traicionado y crucificado por sus anteriores amigos,
los apóstoles de los Medios; cómo los Caballeros mercenarios del
Sombrero Rojo llevaron el evangelio del Pingüino a las salas de las
Corporaciones; e incluso de la disputa entre los cofrades del Gnomo y
KDE acerca de una Licencia de troll. Pero todas esas cosas están
descritas en otra parte, en los Libros de los Hechos del Pingïno, y
las Crónicas de la Cuarta Era, y supongo que si narrásemos todas ellas
llenaríamos un montón de DVDs tan profundo y peligroso como un Grupo
de Noticias de Usenet.
Ahora puedes programar en el poder de las Fuentes; Que el Núcleo, las
Librerías y las Utilidades sean contigo, a través de todas las
Distribuciones, hasta el fín de la Época. Amén.
[ 1 comentario ] ( 7259 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 2.9 / 583 )jueves, mayo 31, 2007, 12:10 AM - /dev/random
[ 2 comentarios ] ( 3501 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 577 )sábado, marzo 24, 2007, 08:24 PM - Tecnología, Opinión
Llevo ya unos pocos de años recorriendo CPDs de grandes empresas, organismos públicos (incluyendo a algún hospital) y me he encontrado con que raro es el sitio donde hay una política de gestión del almacenamiento
Muchas veces se confunde un producto con una política. Tener una SAN (Storage Area Network) no significa que se disponga de una una política de gestión del almacenamiento; es más, muchas veces las SAN se usan como su fueran "un gigantesco pendrive", un despilfarro inmenso.
Pero volvamos al tema de la gestión del almacenamiento. No quiero contar un rollo teórico de quince páginas, ni hablar de productos que ayudan a definir una política de gestión del almacenamiento. Empecemos por lo básico: lo más crítico de la informática son los datos. Y los datos se almacenan (tras unas pocas capas de abstracción) en dispositivos. ¿Pero son todos los datos iguales?
Y es esa la primera pregunta que nos tenemos que hacer. No tienen las mismas necesidades de almacenamiento una base de datos que un buzón de correo electrónico que un servidor de ficheros cargado de .doc y .xls. Vamos a intentar formalizarlo un poco haciéndonos unas preguntas:
¿Qué rendimiento de acceso necesito para acceder a estos datos?
¿Qué disponibilidad requieren estos datos?
¿Qué accesibilidad requieren estos datos? ¿Deben estar siempre disponibles? ¿De qué forma?
¿Cómo "envejecen" estos datos? Es decir, ¿varian las respuestas a las preguntas anteriores con el paso del tiempo? ¿Y dentro de una semana? ¿Y dentro de un mes? ¿Y dentro un año? ¿Y dentro de 5 años?
Todas las preguntas anteriores evaluan distintos aspectos de la información: cómo debe protegerse, como y cuánto se accede, y como varían los parámetros anteriores a lo largo del tiempo. Por poner un par de ejemplos tontos, tal vez no deba almacenarse igual un correo electrónico de ayer que uno de hace 2 años. O quizás no tengan las mismas necesidades de almacenamiento el log de un servicio de ayer que el log generado hace unos meses.
Los párrafos anteriores dan una visión centrada en los datos. También es necesario tener un ojo puesto en la infraestructura actual (y futura) del CPD en el que nos movemos: ¿a quién no le ha pasado que tiene una máquina corta de espacio y luego tiene espacio de sobra en otras?
La gestión del almacenamiento es una disciplina que pretende poner un poco de rigor en todo esto. Así, estudiando detenidamente las necesidades de almacenamiento es posible decidir una política de gestión del espacio así como realizar compras de material con la seguridad de que se le va a dar un buen aprovechamiento.
Todo este tema (que a mi particularmente me apasiona), simplificándolo un poco, se basa en dos pilares fundamentales: jerarquización del almacenamiento y ciclo de vida de la información
La jerarquización del almacenamiento se suele conocer por sus siglas en inglés, HSM (Hierarchy Storage Management). Como casi todo en informática, la primera implementación fue en sistemas Mainframe. Se trata del conjunto de estrategias de administración del almacenamiento según las cuáles es posible identificar y definir la mejor utilización de los recursos hardware a través del movimiento de los mismos de un medio de almacenamiento disponible a otro, basándonos en un juego de políticas predefinididas y estando soportadas dichas políticas por el hardware y software adecuados.
Hablando en plata: mientras más rápido es un soporte de almacenamiento , más caro suele ser. Mientras más queramos proteger una información (raid, backup, etc), más caro nos costará. Y es por eso que hay que buscar un equilibrio entre rendimiento, disponibilidad y accesibilidad. Y nada mejor que aclararlo con ejemplos:
Para una base de datos crítica quizás sea necesario poner toda la carne en el asador y elegir almacenamiento SAN, con conexiones de fibra, y almacenado sobre un nivel de raid de alto rendimiento y con buena tolerancia a fallos (ej: un raid 10), con una buena política de respaldo. Se trata por tanto, de una situación donde prima el rendimiento de acceso, y que requiere que los datos estén bien protegidos. El coste por gigabyte es alto.
En cambio, tal vez para un servidor de ficheros departamentel baste con una NAS basada en discos SATA usando protocolos como NFS/CIFS, estando los datos almacenados en un raid5, con una política de respaldo estándar. Se trata de un caso intermedio, donde se tienen unas necesidades de acceso, rendimiento y protección de la información que no son tan elevadas como el caso anterior. El coste por gigabyte es medio.
Y por último, los logs de acceso de los proxy-caché squid pueden almacenarse a largo plazo en dispositivos ópticos como dvd y/o magnéticos como cinta, pues rara será la vez que tengamos que acceder a esa. En este caso, prima más el espacio neto total, siendo el coste por gigabyte relativamente bajo.
Por tanto, la jerarquización de la información nos ayudará a elegir entre tecnologías SAN, NAS, DAS, librerias de cintas y almacenamiento óptico, nos ayudará a decidir entre los niveles de raid a emplear, qué política de backup hacer y nos permitirá tener criterio a la hora de elegir dispositivos de almacenamiento para nuestra información.
El almacenamiento de la información se convertirá por tanto en una pirámide, estando en la base aquel almacenamiento cuyas necesidades de rendimiento y disponibilidad sean más bajas (siendo éste el almacenamiento más barato) y mientras más subamos en la pirámide mayor será el precio, el rendimiento y/o la disponibilidad de la información.
La jerarquización de la información nos permite responder a las preguntas de cómo debe protegerse la información, como y cuánto se accede. Pero nos falta la otra mitad del puzzle: ¿cómo varía esto con el tiempo?
La respuesta a esta última pregunta es el uso de técnicas de Ciclo de Vida de la información. Podríamos definirlo como el conjunto de políticas que permiten una adecuada jerarquización del almacenamiento basando la decisión en un conjunto de reglas que se ajustan a la realidad del negocio.
Así, es posible definir una política para que ciertos datos suban o bajen en la estructura jerárquica piramidal comentada hacer un par de párrafos, consiguiendo un equilibrio entre coste, rendimiento, disponibilidad y acceso.
El ciclo de vida es más importante de lo que parece: se está produciendo una explosión de uso del almacenamiento, y elegir el soporte adecuado para la información nos puede hacer ahorrarnos mucho dinero y lograr una mejor eficiencia en nuestro CPD.
Analicemos un ejemplo práctico: un cliente nos plantea la necesidad de servir ficheros a una red de varios miles de usuarios en una inmobiliaria. Este servidor de ficheros va a almacenar documentos .doc y .xls, pero también almacena complejas y pesadas imágenes para el uso de 10-12 arquitectos. Se estima que el espacio útil total ha de ser de 4 terabytes, y el cliente no quiere hacer un desembolso elevado.
Para resolver este problema nos debemos plantear las siguientes preguntas:
* ¿Qué necesidades de acceso tiene la información?
* ¿Qué criticidad tiene la información almacenada?
* ¿Cómo varía lo anterior con el tiempo?
Para responder a la pregunta ¿Qué necesidades de acceso tiene la información? Por la descripción del problema, entiendo que lo que nos requieren es un servidor de ficheros NAS que prestará servicio servicio a los usuarios mediante protocolos como CIFS o NFS. Puesto que la información se va a servir mediante una red ethernet, podemos aventurarnos a decir que el caudal máximo va a ser de 1 gigabit por segundo.
Por tanto, tenemos claro que poco beneficio vamos a obtener empleando un sistema de entrada/salida con un rendmiento mucho mayor que ese gigabit por segundo, pues el cuello de botella va a estar en la red ethernet.
Tenemos que averiguar también qué porcentaje del espacio total en disco va a ser usado por los usuarios "normales" y cuánto va ser empleado por los arquitectos, así como una estimación del tamaño medio de los ficheros de cada uno de estos tipos de usuarios. Así, los ficheros .doc tendrán un tamaño medio de 1 megabyte, los .xls un tamaño de 200 kilobyes mientras que los ficheros de los arquitectos tienen tamaños de varias decenas de megabytes.
También es necesario analizar como se accede a los ficheros. Normalmente los usuarios crean y modifican a diario unos cientos de ficheros .doc y .xls, mientras que los arquitectos solo suelen trabajar con apenas una docena de ficheros. Esto nos dará una idea de la concurrencia de acceso a la información.
Para responder a la pregunta ¿Qué criticidad tiene la información almacenada? es necesario analizar el ritmo de modificación de los contenidos, para poder elegir una política de backup adecuada, así como los niveles de raid a elegir. El cliente considera razonable una parada de 4-5 horas en caso de fallo catastrófico, pero por lo general el sistema ha de funcionar al menos el 95% del año laboral. Esto nos da una idea de que no parece crítico emplear técnicas de alta disponibilida/clustering, por lo que con un solo servidor parece bastar, con unos niveles de garantía con el fabricante de hardware para que en menos de 4-6 horas podamos tener un recambio de la pieza en caso de fallo hardware.
Mi solución para este problema (ojo, la mía, invito al lector a que dé la suya, esto es un ejemplo didáctico, no un ejemplo exhaustivo) sería el uso de un servidor x86 tipo rack con 4 gigabytes de ram, electrónica de red gigabit, fuentes de alimentación redundantes y con sistema operativo RedHat Enterprise Linux. Este servidor contará con dos sistemas de almacenamiento externos tipo DAS: una bandeja de discos SAS con 8 discos de 146 gigabytes y 10.000 rpm y con otra bandeja de 14 discos SATA de 750 gigabytes y 7.200 rpm.
Sobre este almacenamiento antes descrito, definiría dos raids: El primer raid estaría formado por 7 discos SAS, estando uno de los discos en spare. Eligiría un nivel de raid5, implementado por hardware, respaldado por una batería de caché. El espacio util sería de aproximadamente 1 terabyte.
El segundo raid estaría formado por 13 discos sata, quedando el número 14 como spare. Eligiría un raid6 por software, empleando mdadm . El espacio útil es de casi 9 gigabytes y medio. Elijo hacer un raid6 porque tengo muchos discos en el mismo raid, no porque la criticidad sea mayor que en el raid SAS.
De esta forma tengo un almacenamiento caro de alto rendimiento de discos SAS (más caro), que es donde va a estar la información que se esté usando más habitualmente y otro volumen de discos SATA donde estarán los ficheros que menos se usen, así como backups de los últimos ficheros que se hayan modificado. Haciendo uso del software LVM integrado en RedHat Enterprise Linux puedo incrementar el tamaño de cualquiera de los raids de manera sencilla. Éste mismo software me permitirá hacer "snapshots" periódicos de la información y almacenarlos en el raid SATA para poder tener así un backup "near line" sin tener que hacer uso de la libreria de cintas. El comando rsync también nos puede ser de utilidad para mantener copias de ficheros individuales.
Dicha librería de cintas se usaría para copias de seguridad "off-line" a almacenar en un armario ignifugo. Se harán copias diferenciales de los snapshots cada día, una copia incremental del volúmen completo cada fin de semana y copias totales cada mes.
Por otra parte, emplearía bonding en las dos tarjetas gigabit integradas en la máquina para tener un caudal efectivo de 2 gigabits por segundo, y con la electrónica de red adecuada podría tener redundacia de acceso a la red de datos, para que el fallo de un conmutador o un cable o de una de las tarjetas de red no impida el acceso al servicio.
El sistema de almacenamiento funcionará de la siguiente manera: se configurará el software samba para integrarse en el directorio activo actualmente existente en el cliente y emplear el protocolo CIFS para servir los ficheros.
Por último, definiría una política de ciclo de vida de la información según la cual si un documento .doc o .xls no ha sido accedido en 7 días se mueva del almacenamiento SAS al SATA (basta con un enlace simbólico). Los ficheros de los arquitectos tendrán una política similar, pero con una persistencia de 15 días.
A su vez, si un fichero .doc o .xls que está en SATA es accedido por más de 5 usuarios en menos de 8 horas, se ha de mover al almacenamiento SAS, ajustando el enlace simbólico.
Esta política es fácilmente configurable con un par de scripts en el cron, pero se podría emplear un software específico si la complejidad creciese.
De esta forma, con la política definida, los ficheros que se usen con poca frecuencia y los backups estarán en el almacenamiento SATA, que es más barato y con mayor capacidad, mientras que los ficheros con mayor uso/concurrencia estarán en el almacenamiento SAS, más pequeño pero con mayor rendimiento.
Una vez visto el ejemplo (que repito, es un ejemplo didáctico y simplificado), mi recomendación respecto a la gestión del almacenamiento es que hay que dejarse asesorar. Que alguien con experiencia nos ayude a la definición e implantación de una política adecuada nos puede hacer ahorar una importante cantidad de dinero, y hará que nuestros datos estén accesibles y protegidos.
[ 4 comentarios ] ( 3504 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 559 )sábado, marzo 3, 2007, 03:51 PM - Tecnología, Opinión
Fuente: web de HP
Copio y pego literalmente:
A technologist who was setting up a computer system for a law firm started by asking the attorneys exactly what they wanted the system to do.
One said, "I want to be able to ask the computer how much money I'm owed by clients, how much I have billed and how much I have in the bank."
"Okay," the techie replied. "We'll set the system up with financial reporting software that will generate a report for you every day."
"No, no," the lawyer said. "I want to ask the computer."
"Okay. We'll set up the report so you can type in a query and get exactly the information you need."
"You don't understand," the lawyer insisted. "I want to be able to walk into my office and say, 'Computer! How much money do I have in the bank?' And the computer will tell me. "They do it that way on Star Trek all the time."
True story.
This example may be extreme, but it does illustrate a common disconnect in the workplace: Business professionals (suits) and technology professionals (geeks) failing to communicate clearly. It’s a phenomenon we’ve dubbed the “Geek Gap.”
There’s no sure-fire prescription for getting technologists and business folks to come together. As a general rule however, the more each side learns about the other, appreciates the thought and talent that goes into that work, and respects all who contribute to the health of the organization, the closer you’ll come to bridging the gap. With those objectives in mind, we offer these 10 tips—five for geeks from suits, and five for suits from geeks.
Tips for Geeks from Suits
1. Learn something about business. Take some basic business courses. Understanding the concepts that underlie management decisions, and what effects IT decisions can have on the bottom line, can give geeks a sense of ownership in the company’s success
2. Focus on the project as a whole, not just the technology. Tech workers tend to be fascinated with technology, often to the exclusion of other aspects of the total job. Organizations are far stronger when everyone looks at the project as a whole.
3. Don’t expect suits to know as much about technology as you do. Geeks live and breathe technology. Suits do not. Sometimes, techies can be downright evangelical about their favorite software. Suits just want it to work so they can get the job done. While suits need to know some computer basics, keep in mind that they are also focusing on a completely different knowledge set for their own jobs.
4. Try to use plain language, and not “geek speak.” Geeky terminologies may be perfectly understandable to your co-workers, but do remember that suits don’t speak geek. They value your opinion and knowledge. It’s important that suits understand what geeks say, so keep it basic, simple to understand and clear.
5. Be involved in more meetings, not fewer. It can be very easy to hide from meetings behind the technology you manage. Problems and questions involving technology often arise in business meetings, and having a knowledgeable geek there can mean the difference between a smooth-running project and one riddled with false starts and unmet deadlines.
Tips for Suits from Geeks
1. Learn something about technology. One of the biggest frustrations for tech workers is dealing with business colleagues who resist learning computer basics. Suits don’t need to become computer wizards, but knowing some essential IT skills is necessary in the modern business world. Suits who take computer courses gain a greater understanding of how technology works, and what it can and can't do. Even a beginner course in programming can help business people better understand computer work and give them more respect for their techie colleagues. .
2. Technology should always be part of the business plan. Don’t leave the technology aspects out of a project until the end. Bring the geeks in on the business development meetings early and keep them informed thoughout the stages of the project. Keeping the technology in mind as the project grows will smooth many of the processes, saving time and money, and raising the chances of success.
3. Build some flexibility into schedules and budgets. Building and working on technological products is as much art as engineering. Allow some flexibility in the calendar and the spending to give your techies the opportunity to build a good product. Otherwise, you may wind up with something on time and on budget, but not on the mark. Geeks would rather get it right before a system goes into production. It’s easier and less expensive than fixing a buggy system already in use.
4. Try to use plain language, not buzzwords. Like any specialized workers, suits have their own words that make their job easier. Whether “incentivizing” the buyer, “gaining traction” with products or putting the “paradigm shift” spin on “restructuring,” geeks understand that language can be powerful. However, keep in mind geeks don’t want to be sold on an idea. Limit the motivational talk.. Sometimes, it’s not a “challenge” or a “hurdle.” It might just be a problem to fix, and we can work together much better if we both use plain language.
5. Talk to us directly. Many companies designate one employee as a liaison between the technology department and other business areas. Having a liaison is great, but making this person the only conduit for information to and from the tech department is a mistake and will create bottlenecks. Feel free to approach whoever can get the information you need..
No advice we could offer in a short article amounts to the final solution to an intricate and ingrained problem like the Geek Gap. However, anything you can do to get geeks and suits talking to one another can help your organization span the Geek Gap, often with dramatic results.
[ 1 comentario ] ( 3509 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 597 )sábado, enero 27, 2007, 01:27 PM
Se debe haber congelado el infierno, se acerca el fin de los tiempos: el miércoles pasado aprobé el examen práctico del carnet de conducir... me he sacado el teórico y el práctico a la primera, seguro que esto es una señal de la venida del príncipe de la oscuridad...
Yo calculo que en dos o tres años sabré lo BÁSICO como para poder denominarme conductor. Por ahora lo que tengo es un examen aprobado, nada más, y tengo muy claro que no tengo ni pu*a idea de conducir. Prudencia. Y buenos alimentos.
Por otra parte, el próximo día 1 de febrero me voy a Guildford, en Reino Unido, a presentarme a éste examen de RedHat. Esta es una de las 5 pruebas que debo superar para ser RHCA, es decir, arquitecto de RedHat (ya soy RHCE, ingeniero). A ver que pasa...
Y qué es la vida sino un montón de pruebas. Y es que lo bonito es el camino, no el final...
[ 8 comentarios ] ( 1110 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 584 )domingo, enero 7, 2007, 08:29 PM - Tecnología
Este año uno de los regalos de reyes para la nena ha sido un disco duro externo usb de 80 gigabytes. Y ahora viene el problema: ¿Qué sistema de ficheros usar?
Su ordenador principal en casa es un Apple ibook ppc de 12" con MacosX. En el trabajo tiene un x86_64 con Fedora Core 6. Y más de un amigo tiene Windows XP SP2. Tres sistemas y un sólo disco externo.
La elección sencilla parece ser fat32. A fin de cuentas, lo leen y escriben MacosX, GNU/Linux y Windows. Pero resulta que el tamaño máximo de un fichero en fat32 son 4 gigabytes, lo cual es una lata cuando se quiere copiar uno imágenes de dvd completas (4,4 gigabytes), hay que recurrir a split (o su equivalente en el otro mundo, hacha).
Puesto que fat32 es limitado, veamos como está la cosa con NTFS. Resulta que por defecto MacosX y GNU/Linux son capaces de acceder en modo lectura, pero no en escritura. Existen proyectos como éste o éste para añadir soporte de escritura para GNU/Linux. Por desgracia, para MacosX el panorama no es tan bueno y los proyectos para añadir soporte de escritura para NTFS aún están un poco verdes.
Veamos ahora la posibilidad de usar HFS+. Tanto GNU/Linux como MacosX leen y escriben perfectamente en este formato. Existe una herramienta para Windows llamada Macdrive que posibilita la lectura/escritura, pero son 49,95 $. Desconozco si existe alguna otra utilidad para Windows que soporte HFS+, así que te animo, desconocido lector, a que aportes tu experiencia, que en google ya se buscar yo.
Pues nos queda ext2/ext3. En GNU/Linux, como es lógico, está perfectamente soportado, y existen utilidades gratuitas para acceder en lectura/escritura a discos en este formato tanto en MacosX como en Windows. Parece que al final esta es la mejor solución, pero no deja de ser un peñazo tener que instalar drivers adicionales en el ordenador de un amigo para acceder a un disco externo...
Alguno dirá que la solución es la virtualización. Con Parallels, qemu, xen o vmware uno puede cargar el sistema operativo que necesite en cada momento, pero por desgracia esta no es una solución muy práctica cuando uno le presta el disco a una persona (sin conocimientos de informática, se entiende) para que te copie el dvd de sus vacaciones...
Otros dirán que lo más fácil es llevarse uno el portátil, montar el dispositivo con el sistema operativo que más le guste y luego acceder a los datos del otro ordenador usando cifs/nfs/ftp/scp, pero ya se tiene que llevar uno el portátil para copiarse unos datos, una carga más.
En fin, parece que al final ext3 es la mejor elección para un disco duro externo "multiplataforma". ¿Se te ocurre algo mejor, desconocido lector?
[ 5 comentarios ] ( 4150 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 694 )miércoles, diciembre 6, 2006, 12:23 AM - Humor, /dev/random
Gracias a la Mujer tirita por existir :-)
[ 3 comentarios ] ( 1425 visualizaciones ) | [ 0 trackbacks ] | enlace permanente |
( 3 / 846 )
