10 minutos tiempo de lectura
Questo post è disponibile anche in Italiano
El soporte a las cargas de trabajo generadas de las grandes bases de datos requiere muchas veces de arquitecturas especializadas o DB machine.
Consideremos la siguiente definición de DB machine según Wikipedia
«Un database machine (máquina de base de datos) o procesador de back-end es un hardware especial que almacena y recupera datos de una base de datos. Un database machine está especialmente diseñado para el acceso a la base de datos con los servidores de front-end estrechamente acoplados (tighly coupled) por un canal de alta velocidad mientras que el servidor de la base de datos está acoplado libremente (loosely coupled) a través de la red. El front-end recibe los datos y los muestra, el back-end, por otro lado, analiza y almacena los datos de los procesadores de front-end. Los database machine dan como resultado un mayor rendimiento, un aumento de la memoria principal del host, un aumento de la seguridad de la base de datos y una disminución del costo de fabricación».
Es claro que el término clave para definir un DB machine es “solución integrada” hardware (server, network, storage) y software (DBMS). Según esta definición existen 2 implementaciones posibles: un appliance software preconfigurado con el hardware necesario para ejecutar dicho software (propuesta típica del DBMS vendor) o un appliance hardware preconfigurado con el software necesario para ser ejecutado en ese hardware (propuesta típica del hardware vendor).
Aunque a primera vista las dos arquitecturas pueden parecer similares, cada una de ellas presenta ventajas y desventajas y las implicaciones sobre su implementación en un datacenter son bien diferentes.
En este post analizaremos ambas arquitecturas con la idea de proporcionar algunos puntos de reflexión para orientarse en la decisión de cual “appliance” representa una arquitectura valida según exigencias aplicativas y de business.
Desafíos de un DBMS en un data center
Rendimiento: El primer desafío que enfrenta un DBA es obtener el “máximo rendimiento posible” de la base de datos. El motivo es simple, un DB performante genera un “business value” mayor y evita descontentos por parte de los clientes internos a la TI. Mantener un DB eficiente es una de las tareas que requieren mayor tiempo al DBA. El “tuning” de un DB abarca desde la implementación de parámetros a nivel del DB, del SO, creación y manutención de índices, optimizaciones al código SQL, etc.
Disponibilidad y protección de los datos: en términos de disponibilidad y protección de datos, las bases de datos de tipo “mission critical” necesitan de alta disponibilidad y SLO (Service Level Objectives) más estrictos. Las fallas comunes incluyen fallas de discos, corrupción de datos, conectividad y nodos, necesidades de upgrade o actualizaciones del software sin interrupciones de servicio, etc.
Creaciones de copias y provisioning de nuevos ambientes: Todos los DB requieren la creación y manutención de un número de snaps (PiT copies) o clones sea para realizar copias de seguridad como asi también para suportar varios procesos de business (reporting, creación y refresh de ambientes de test y desarrollo, etc). El provisioning de nuevos ambientes a partir de las copias de datos es una tarea que debe ser efectuada en modo ágil y veloz para no causar retrasos en las actividades de desarrollo de aplicaciones debido a la indisponibilidad de la infraestructura.
Reducción de costes: OpEx y CapEx también son un desafío. Los costos de licencias de un software DBMS aumentan con la cantidad de núcleos de CPU. Las dificultades o menos de integrar un appliance con el resto de la infraestructura existente en el datacenter aumenta el CapEx. Dependiendo del grado de modularidad y escalabilidad del appliance, la adquisición de más hardware o software aumenta los costos tanto de OpEx como de CapEx.
Appliance software + hardware vs appliance hardware + software
Por simplicidad utilizaremos como sinónimos DB machine propietario = appliance propietario (propuesta del DBMS vendor) y DB machine open = appliance open (propuesta del hardware vendor).
Un DB machine open que incluya el mejor sistema de almacenamiento del mercado + la mejor tecnología de network + la mejor tecnología de server; ¿permiten de ejecutar un DB con el máximo de rendimiento, protección y facilidad de uso posibles? Dicho de otro modo; ¿hasta qué punto es posible comparar un DB machine open con un DB machine propietario?
Analicemos con un cierto detalle las respuestas a estas cuestiones.
Rendimiento: A grandes líneas, un DB machine propietario utiliza a nivel de software algunas funcionalidades especiales que no es posible ejecutar en un “appliance open” (el DB vendor no permite su implementación). Estas funcionalidades especiales han sido desarrolladas para hacer al appliance propietario un sistema sumamente veloz en la ejecución de determinados códigos SQL. Ahora bien, si son las funcionalidades especiales las que hacen veloz a un appliance propietario cabe preguntarse: 1) estas funcionalidades especiales son usadas siempre en los appliance propietarios?, 2) es posible en algún modo para un appliance open cubrir este gap de rendimiento con funcionalidades hardware u otras funcionalidades software?
Existe sólo un modo de acceder lo más rápido posible a los datos y es NO ACCEDER o cuanto menos, evitar todo lo posible de efectuar I/O en el back-end (aunque este sea de tipo flash). Para obtener el máximo rendimiento, una aplicación necesita que los datos para construir su working-set se encuentren ya a algún nivel de cache en el camino de los datos, en teoría cuanto más cerca de la CPU de los servidores mejor.
Para las cargas de trabajo de tipo casual (OLTP) no es posible prever en anticipo cuales datos deben estar en memoria, el acceso es propio de naturaleza aleatorio. Esto significa que en los workload OLTP tanto un appliance propietario como un appliance open configurados con la misma cantidad de cache tendrán un comportamiento de rendimiento similar. En entornos OLTP, el mayor o menor nivel de performance dependerá del número de “hits” en cache, valor que está en relación directa con la cantidad de cache disponible, la frecuencia de acceso al mismo dato y la localización espacial de los datos (LoR – Locality of Reference).
Para las cargas de trabajo de tipo DWH es posible aumentar el rendimiento si los datos necesarios al working-set pueden “predisponerse” en la cache antes de que sea necesario recuperarlos del back-end. En entornos de DWH, las funcionalidades especiales de un appliance propietario son capaces, dependiendo de la complejidad de la sentencia SQL, de leer en anticipo los datos del back-end (almacenamiento) y enviarlos al front-end (servidores). Este tipo de acceso secuencial (scan) preventivo implementado en los DB appliance propietarios puede ser considerado análogo a los algoritmos de “prefetch” que algunos sistemas de almacenamiento evolucionados utilizan ya desde hace tiempo. En un DB machine open, cuando el sistema de storage reconoce un I/O de tipo secuencial anticipa (“prefetch”) la lectura de más datos y los envía a su cache evitando de este modo a los servidores la necesidad acceder a los discos. Si bien es correcto afirmar que los algoritmos de prefetching del storage de un DB machine open son agnósticos al tipo de aplicación y pueden leer más datos de los estrictamente necesarios al working-set, esto puede influenciar un mayor o menor uso de la cache pero no influencia un mayor o menor rendimiento aplicativo.
Podría argumentarse que, desde el punto de vista del rendimiento, predisponer los datos a nivel de la cache del sistema de almacenamiento, como en un DB machine open, no es lo mismo que predisponer los datos a nivel de la cache de los servidores como sucede en un DB machine propietario. En el segundo caso los datos se encuentran más cerca de la aplicación, no hay ninguna SAN de por medio y por lo tanto se debería obtener un mayor rendimiento gracias a una menor latencia. Sin embargo, debemos considerar que, en fin de cuentas, la latencia es función de la distancia que una señal tiene que atravesar. Una SAN utiliza una tecnología de fibra óptica, donde la señal viaja a una velocidad cercana a la de la luz. Por lo tanto, para una distancia de pocos metros la latencia introducida de la SAN, cuando configurada correctamente, es irrelevante (< 0.5 microsegundos) y acceder a la RAM de los servidores o a la DRAM del storage non es una gran diferencia.
DB Machine propietario vs DB appliance open, otras consideraciones
Con respecto a las características de afidabilidad, protección de los datos, facilidad de uso e inclusión en el data center; ¿un appliance open es comparable a un appliance propietario?
Afidabilidad, RAS (características enterprise)
RAS define las características de los sistema enterprise, características que van más allá de la alta disponibilidad y más allá de la simple redundancia de los componentes. RAS significa operaciones y actualizaciones sin interrupciones, y estar «siempre en línea». Operaciones tales como la actualización del software (patching) en algunos DB machine puede hacerse solo en modo serial, actualizando parciales grupos de componentes por vez y solo si el back-end adopta una múltipla (raid >2) protección de los datos. Al contrario, in un appliance best-of-breed open de clase enterprise las actividades de actualización del software de la “parte datos” no presenta ninguna de estas complicaciones y es posible actualizar el sistema en un tiempo < 5 segundos sin ningún impacto sobre el rendimiento o la erogación del servicio.
El siguiente link proporciona una descripción detallada de las características RAS
Protección de los datos (replicación local y remota)
En un DB machine propietario las funcionalidades de protección de los datos (replicación) son por lo general enteramente basadas en el software del DB. En muchos DB machine propietarios los mecanismos de replicación remota soportan la copia de un solo DB a la vez. Si el appliance contiene diversos DB y sucede un desastre a nivel del entero DB machine o data center, no será fácil obtener en el sitio di Disaster Recovery todos los DB en la misma situación que era presente en el sitio de producción (consistencia temporal global).
Contrariamente el sistema de almacenamiento de un DB machine open cuenta con mecanismos hardware de protección de datos extremadamente más eficientes. Esto significa tener la flexibilidad para manejar cualquier nivel de servicio, aplicación o grupos relacionados de aplicaciones sin importar cuánto o cómo cambie el ambiente. La replicación hardware posibilita también la disminución de la banda necesaria gracias a mecanismos de compresión y deduplicación sobre la línea.
Gestión e integración con otros componentes en el data center
Appliance open significa también la posibilidad de ejecutar junto al DBMS otras aplicaciones físicas o virtuales y sobre todo evitar el lock-in con la plataforma subyacente. Los appliance open son, por su naturaleza, fácilmente integrables con otros componentes presentes en el centro de datos y permiten de agregar en modo separado componentes computacionales o de almacenamiento según la necesidad.
En lo que se refiere a la gestión, numerosos plug-in permiten la visión unificada del DBMS con el DB machine open como así también la gestión automática de los mecanismos de copia.
Para concluir
En determinadas circunstancias, cuando es posible ejecutar específicas funcionalidades especiales, un DB machine propietario puede ofrecer mejores rendimientos.
Las funcionalidades especiales de los DB machine propietarios son aplicables casi exclusivamente al ámbito DWH y no tienen ningún efecto para cargas de trabajo de tipo casual (OLTP).
Los DB machine propietarios son difícilmente integrables con otros componentes dentro un data center y no ofrecen la posibilidad de consolidación de workload aplicativos mixtos.
Los nuevos desarrollos en el campo del almacenamiento flash tales como NVMe, SCM y NVMeoF permiten a un DB appliance open de proporcionar un ancho de banda mucho mayor del que una aplicación SQL es en grado de generar.
Un DB appliance open beneficia de los constantes desarrollos en ámbito server, cpu, networking, storage – (best-of-breed) – evita el lock-in y facilita, según la necesidad, la sustitución y actualización independiente de componentes individuales.
Cuando un DB appliance open se configura siguiendo una “reference architecture”, del punto de vista de la validación y soporte este tipo de arquitecturas pueden ser equiparada a un DB appliance propietario.
Para mayor información:
Dell EMC Ready Solutions for Business Applications
Dell EMC Soluciones Convergentes
#IWork4Dell
Este post también está disponible en: Italiano
