Contenido
- Sistema de archivos de Google: un gran estudio de caso
- Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
- Una mirada a la tecnología central
- ¿Cómo lo logran otros grandes sistemas?
- Mantener un DFS
Para llevar:
Los desarrolladores e ingenieros necesitan trabajar continuamente para acelerar y mejorar los servicios en plataformas que han crecido mucho más allá de sus arquetipos clásicos de la década de 1990.
Con todo el rumor sobre los enormes centros de datos de la NSA que contienen miles de millones de datos sobre nuestra vida privada, hay una cosa de la que no se ha hablado mucho, al menos en CNN. Implica un problema de ingeniería que ha surgido junto con la tecnología en la nube, big data y los impresionantes centros de almacenamiento de datos físicos que ahora se están construyendo en todo el mundo. ¿Así que qué es lo? Bueno, no importa quién administre uno de los gigantescos sistemas de TI que manejan estas instalaciones, existe la necesidad de sistemas de software que ayuden a que todos esos datos entren y salgan de la tubería rápidamente. Esa necesidad representa una de las preguntas o acertijos de TI más interesantes que enfrentan los profesionales en la actualidad.
Como señalan muchos expertos, la extrema demanda actual de procesamiento de datos va mucho más allá de los enfoques tradicionales. En pocas palabras, el uso de estructuras de bases de datos simples y herramientas como la interfaz de consulta SQL no proporcionará suficiente potencia de procesamiento o funcionalidad para los sistemas propietarios que se han desarrollado en los últimos años. Los archivos de las grandes compañías tecnológicas de hoy necesitan tecnología extremadamente escalable. Necesitan herramientas de procesamiento de datos que puedan generar resultados de entrada y salida en un volumen mucho mayor que el que puede facilitar un solo servidor. Necesitan soluciones que puedan incrementarse rápidamente para crecer, soluciones que incluyan niveles complejos de inteligencia artificial, soluciones diseñadas para una fácil administración por parte de un departamento de TI.
La pregunta es, ¿cómo las empresas y agencias gubernamentales conquistan las limitaciones de la vía tradicional de manejo de datos? Aquí eche un vistazo a una opción muy prometedora: software que maneja grandes datos y la administración de múltiples centros de datos.
Sistema de archivos de Google: un gran estudio de caso
La tecnología patentada que Google utiliza para acceder a sus centros de datos es uno de los mejores ejemplos de modelos comunes para el manejo de grandes datos y la administración de múltiples centros de datos. El Sistema de archivos de Google (GFS), desarrollado en 2003, está diseñado para admitir el gran volumen de enmiendas de alta velocidad a los sistemas de datos que son parte de obtener tanta información nueva dentro y fuera de una sola plataforma a medida que millones de usuarios hacen clic en al mismo tiempo. Los expertos se refieren a esto como un sistema de archivos distribuido, y usan el término "almacenamiento de objetos de datos" para describir estas técnicas altamente complejas. En realidad, sin embargo, estos términos ni siquiera arañan la superficie en términos que describen lo que está funcionando.
Individualmente, las características y componentes que componen un sistema como GFS pueden no ser innovadores, pero son complejos. Muchos de ellos se han cubierto en este sitio como innovaciones relativamente nuevas que forman parte de las bases para un nuevo sistema de TI global siempre conectado y siempre conectado. Colectivamente, un sistema como GFS es mucho más que la suma de sus partes: es una red en gran parte invisible pero enormemente compleja, repleta de datos individuales que se lanzan de esta manera y que en un proceso que, si se modela completamente visualmente, parecería un caos. Comprender a dónde van todos los datos requiere mucha energía y compromiso, como admitirán fácilmente quienes manejan las estaciones de batalla de estos sistemas.
"Hay demasiados detalles que tienen un profundo impacto en las áreas de usabilidad, incluida la fragmentación externa e interna, las actualizaciones basadas en registros frente a las implementadas y los niveles de coherencia de las transacciones, para resumir la forma en que funciona en una sola oración sucinta. ", dice Momchil Michailov, CEO y cofundador de Sanbolic.
"Un sistema de archivos distribuido es un agregador distribuido de espacios de nombres locales y espacios libres de nodos participantes, o un sistema de archivos local que se ejecuta en múltiples nodos que acceden al almacenamiento compartido con la ayuda de un componente de administrador de bloqueo distribuido", dijo.
Kerry Lebel es gerente senior de productos en Automic, una compañía conocida por sus plataformas de automatización escalables. Lebel dice que si bien es exacto describir un DFS como un sistema que simplemente asigna cargas de trabajo a los servidores conectados a piezas de hardware de bajo costo, eso realmente no cuenta toda la historia.
Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
No puede mejorar sus habilidades de programación cuando a nadie le importa la calidad del software.
"Lo que terminas perdiendo es todo el factor genial de cómo hacen lo que hacen ", dijo Lebel.
Cuando te alejas de los detalles técnicos y solo piensas en la idea básica detrás del sistema de archivos distribuido, el "factor genial" del que habla Lebel es evidente. Estos sistemas de manejo de grandes datos reemplazan los viejos sistemas de archivos / carpetas con estructuras que involucran no solo múltiples sistemas de entrega, sino también un enfoque "orientado a objetos", donde una gran cantidad de unidades se escapan aquí y allá para evitar cuellos de botella.
Piense, por ejemplo, en un sistema de autopistas de última generación, donde cientos de miles de automóviles no solo se canalizan por una recta de varios carriles, sino que se recogen en pequeños y limpios afluentes de hojas de trébol u oxbow, que se giran y se envían hacia sus destinos en una variedad de desvíos. Desde el cielo, todo parece tan coreografiado como un reloj suizo. Ese es el tipo de modelo visual que los ingenieros observan cuando sueñan con nuevas formas de enrutar la información alrededor de las limitaciones al "patearla" a diferentes niveles de un esquema de contención de datos de varios niveles. Dejando de lado las especificaciones, este es el objetivo de nivel superior de un sistema de manejo: mantener esos objetos autocontenidos con sus metadatos incrustados moviéndose a la máxima velocidad a donde deben estar, alcanzar objetivos de consistencia, satisfacer a un usuario final, o incluso para informar una observación o análisis de alto nivel.
Una mirada a la tecnología central
Un artículo de Sean Gallagher que apareció en Ars Technica desglosa el diseño de GFS en partes algo más manejables, e insinúa lo que hay debajo de la hoja en Google.
GFS comienza con un modelo redundante y tolerante a fallas para lecturas y escrituras de datos. La idea aquí es que, en lugar de escribir una actualización específica en una sola unidad, los nuevos sistemas escriben fragmentos de datos en múltiples destinos. De esa manera, si una escritura falla, quedarán otras. Para acomodar esto, un componente de red principal aglutina el manejo de datos a otras unidades subordinadas, volviendo a agregar los datos cuando un cliente lo "solicita". Todo esto es posible gracias a un protocolo de metadatos que ayuda a identificar dónde se encuentran ciertas actualizaciones y resultados de transmisión dentro del sistema más amplio.
Otro aspecto muy importante de esto es cómo estos sistemas pesados duplicados imponen la consistencia de los datos. Como señala Gallagher, el diseño de GFS sacrifica cierta consistencia al mismo tiempo que "impone la atomicidad" o protege el principio de cómo se actualizan los datos en varias unidades de almacenamiento para que coincidan con el tiempo. El "modelo de consistencia relajada" de Google parece seguir la teoría esencial del modelo BASE, que proporciona más flexibilidad a cambio de un marco de tiempo más largo para la aplicación de la consistencia.
¿Cómo lo logran otros grandes sistemas?
"Cuando se alcanza una escala suficientemente grande, las inconsistencias o corrupciones en los datos se vuelven inevitables", dice Michailov. "Por lo tanto, un objetivo principal de los sistemas de archivos distribuidos debe ser la capacidad de llevar a cabo tantas operaciones como sea posible en presencia de corrupción, al tiempo que se proporcionan métodos eficientes para enfrentar la corrupción simultáneamente". Michailov también menciona la necesidad de preservar el rendimiento mediante la implementación cuidadosa de la redundancia.
"Por ejemplo, crear metadatos (datos sobre los datos) en cada disco permite que ese disco reconstruya su estructura de datos adecuada si su copia espejo está dañada", dijo Michailov. "Además, los niveles RAID se pueden usar para combatir fallas de almacenamiento en el agregador del sistema de archivos o en los niveles del administrador de volumen compartido".
Al analizar otro modelo de coherencia, Lebel se enfoca en un sistema llamado sistema de archivos distribuidos de Hadoop (HDFS), que él llama un "estándar de facto de la industria".
En HDFS, dice Lebel, cada bloque de datos se replica tres veces en diferentes nodos y en dos bastidores diferentes. Los datos se verifican de principio a fin. Las fallas se informan a NameNode, un controlador de datos que elimina los bloques corruptos y crea otros nuevos.
Todo esto es compatible con los tipos de "datos limpios" que son tan importantes para la integridad de uno de estos sistemas de datos masivos.
Mantener un DFS
Otra mirada muy diferente a GFS proviene de un artículo de octubre de 2012 del escritor Wired Steven Levy. Es mucho más breve para caracterizar el enfoque de software para el manejo colectivo de red de arriba hacia abajo de Google.
"A lo largo de los años", escribe Levy, "Google también ha creado un sistema de software que le permite administrar sus innumerables servidores como si fueran una entidad gigante. Sus desarrolladores internos pueden actuar como maestros de títeres, enviando miles de computadoras para realizar tareas tan fácilmente como ejecutar una sola máquina ".
Hacer esto también implica toneladas de mantenimiento cibernético y ambiental, desde equipos de prueba dedicados que intentan "romper" los sistemas del servidor, hasta temperaturas cuidadosamente controladas en los pasillos de la cripta de datos.
Levy también menciona tecnologías complementarias para GFS, como MapReduce, una herramienta de aplicación en la nube, y Hadoop, un motor de análisis que comparte algunos principios de diseño con GFS. Estas herramientas tienen su propio impacto en cómo se diseñan los sistemas de manejo de grandes centros de datos y qué es probable que surja en el futuro. (Obtenga más información sobre estas tecnologías en The Evolution of Big Data).
Michailov cree que MapReduce tiene el potencial de soportar sistemas de centros de datos cada vez mayores, y habla de una "implementación única" de sistemas de archivos compartidos y agregados que podrían "mantener los nodos de nombre de un sistema de archivos agregado en un clúster compartido con SSD para almacenamiento ".
Por su parte, Lebel ve un alejamiento del procesamiento por lotes (el método compatible con Hadoop) para procesar el flujo, lo que acercará estas operaciones de datos al tiempo real.
"Cuanto más rápido podamos procesar los datos y ponerlos a disposición de los tomadores de decisiones comerciales o de nuestros clientes, habrá una ventaja competitiva mayor", dice Lebel, quien también sugiere reemplazar la terminología de procesamiento anterior con términos que se centren en el usuario final. Al pensar en actividades "sincrónicas" o actividades sincronizadas con acciones del usuario final y actividades "asincrónicas" que son más flexibles en términos de implementación, Lebel dice que las empresas pueden usar SLA y otros recursos para definir cómo funcionará un sistema de servicio dado .
En cierto sentido, todo esto se reduce a que los desarrolladores e ingenieros necesitan trabajar continuamente para acelerar y mejorar los servicios en plataformas que han crecido mucho más allá de sus arquetipos clásicos de la década de 1990. Eso significa mirar críticamente la maquinaria de datos y romper los cuellos de botella de manera que apoyen no solo a una población en crecimiento, sino a ese cambio exponencial que ocurre a una velocidad vertiginosa que los expertos llaman "la próxima revolución industrial". Es probable que quienes abran más terreno en estos frentes terminen dominando en los mercados y las economías del futuro.