Guía de Hardware de Firebird

_by Alexey Kovyazin, última actualización: 30 de noviembre de 2015

A menudo se puede ver la siguiente pregunta en los grupos de soporte técnico de Firebird: “¿Cuál es el hardware de elección para el DBMS Firebird?”. Este tema sigue siendo permanentemente popular porque los requisitos de hardware difieren según las tareas y el hardware en sí cambia con el tiempo.

Decidimos escribir esta guía para proporcionar el conocimiento necesario a cualquiera que quiera elegir hardware verdaderamente eficaz para su base de datos Firebird. Para hacerlo, tendrá que aprender algunos detalles básicos sobre cómo funcionan Firebird, el sistema operativo y, por supuesto, el hardware.

Un Poco de Teoría

Para descubrir qué hardware se adaptará mejor a su base de datos Firebird, tenemos que entender cómo Firebird utiliza sus componentes: CPU, RAM, HDD/SSD y cómo estos componentes interactúan con el sistema operativo (por ejemplo, con la caché de archivos).

Módulos Funcionales del Servidor Firebird

En primer lugar, analizaremos los módulos funcionales de Firebird con la ayuda de la Figura 1:

Figura 1. Módulos de Firebird

Firebird incluye los siguientes módulos funcionales principales:

Objetos de metadatos: vistas, tablas, índices, disparadores, procedimientos almacenados y otros objetos de base de datos. Los objetos de metadatos se encuentran en el espacio de direcciones del proceso de Firebird (puede ser fbserver, fb_inet_server o firebird.exe).
La caché de búferes de páginas contiene páginas de base de datos leídas del disco y se encuentra en el espacio de direcciones del proceso del servidor. El mecanismo de almacenamiento en caché de páginas es bastante complicado, por lo que solo indicaremos que Firebird almacena en caché las páginas de base de datos más utilizadas.
Firebird ordena los registros en memoria (en el espacio de direcciones del proceso del servidor) hasta que la cantidad de memoria utilizada para todas las operaciones de ordenación simultáneas alcanza el límite establecido por el parámetro TempCacheLimit (firebird.conf). Una vez que se supera este límite, se crea un archivo temporal (con la bandera correspondiente del sistema operativo) en la carpeta de archivos temporales y se utiliza para la ordenación. Si hay RAM libre en el sistema, el archivo de ordenación será almacenado en caché por el sistema operativo y la ordenación se realizará en memoria.
Las Tablas Temporales Globales (GTT) se crean como archivos temporales en el sistema operativo. Si el sistema operativo tiene memoria libre, las operaciones con GTT se realizan en RAM.

Operaciones Básicas con Hardware

Veamos cómo los módulos funcionales de Firebird interactúan con los componentes de hardware durante las operaciones realizadas en el curso del trabajo con bases de datos.

Una vez que se inicia Firebird, el proceso del servidor ocupa la cantidad mínima de RAM (varios megabytes) y no realiza operaciones intensivas con la CPU o la RAM.

Cuando se establece una conexión con la base de datos, el servidor comienza a leer sus metadatos y crea los objetos correspondientes en memoria, lo que resulta en que el proceso tome más recursos cuantas más tablas, índices, disparadores y otros metadatos se utilicen. El uso de memoria aumenta, pero la CPU prácticamente no se utiliza en esta etapa.

Cuando el cliente comienza a ejecutar consultas SQL (incluidos los procedimientos almacenados), el servidor realiza las operaciones correspondientes utilizando hardware. Es posible destacar las siguientes operaciones básicas que implican interacción con el hardware:

lectura de páginas de base de datos desde el disco duro,
escritura de páginas de base de datos en el disco duro,
lectura de páginas de base de datos desde la caché,
escritura de páginas de base de datos en la caché,
lectura y escritura de datos en tablas temporales globales,
procesamiento de consultas SQL (por ejemplo, JOINs),
ordenación de registros en conjuntos de resultados.

Cada una de estas operaciones requiere una cierta cantidad de recursos del sistema. La tabla a continuación muestra el consumo de recursos en unidades intensas (1 significa menos intenso, 10 significa más intenso):


	Lectura de una página desde el disco	Escritura de una página en el disco	Lectura de una página desde la caché de búferes de páginas	Escritura de una página en la caché de búferes de páginas	Lectura desde una GTT	Escritura en una GTT	Ordenación de registros	Procesamiento de consultas SQL
CPU	1	1	1	1	1	1	5	10
RAM	5	5	5	5	5	5	5	2
E/S de disco	10	10	1	1	1	1	1	1

Como puede ver, las operaciones que consumen más recursos son aquellas que implican acceso al disco porque los discos siguen siendo el componente de hardware más lento a pesar del progreso de los últimos años relacionado con los SSD.

Esto lleva a una de las formas de optimizar el rendimiento que está totalmente relacionada con el hardware: llevar todas las operaciones de lectura-escritura a la RAM. Pero tenga en cuenta que el enfoque de aumentar la caché de páginas no funciona. Trataremos este tema en detalle en la sección de RAM.

Operaciones Realizadas Simultáneamente

Por lo general, es necesario elegir hardware para un servidor que atenderá a muchos clientes, por lo que es realmente importante entender cómo se implementa el paralelismo de las operaciones.

Desde el punto de vista de los componentes de hardware, podemos hablar del uso paralelo de la CPU, el disco y la RAM. Los CPUs modernos tienen varios núcleos que pueden ejecutar conjuntos de instrucciones en paralelo, por lo que el servidor DBMS distribuye las operaciones entre los núcleos, lo que significa la conclusión de que cuantos más núcleos tenga la CPU, más clientes podrán trabajar en este servidor.

No es tan simple desde el punto de vista de los discos. Cuando los discos duros tradicionales (HDD) leen información, mueven físicamente el cabezal sobre el material magnético a una velocidad finita. Una base de datos puede ser bastante grande, es decir, 3 terabytes de tamaño, y si las consultas SQL de los clientes acceden a sus datos ubicados en diferentes áreas del disco en paralelo, el cabezal del disco saltará entre diferentes áreas del disco, lo que ralentizará seriamente las operaciones de lectura y escritura. Esto aumentará considerablemente la cola del disco mientras que el resto de los recursos (CPU, RAM) están inactivos. Por supuesto, la caché del disco (la caché del HDD o del controlador RAID) compensa esta desaceleración hasta cierto punto, pero no es suficiente.

A diferencia de los HDD tradicionales, las unidades de estado sólido (SSD) son mucho menos propensas a la degradación del rendimiento en caso de acceso paralelo a los datos. La ventaja de un SSD es especialmente evidente cuando se escriben datos en paralelo: nuestras pruebas muestran que un SSD es 7 veces más rápido que un disco SATA (¡enlace!). Sin embargo, los SSD tienen algunos problemas que deben tenerse en cuenta durante su uso (ver Selección de Discos) para evitar ralentizaciones, averías tempranas y pérdida de datos.

Las operaciones con RAM se realizan muy rápido en las computadoras modernas, prácticamente están limitadas solo por el ancho de banda del bus de datos, por lo que estas operaciones no actúan como un cuello de botella incluso si hay muchas consultas SQL paralelas.

Flujos de Datos

Mientras ejecuta consultas SQL, Firebird lee y escribe muchos datos, los transfiere entre módulos funcionales y componentes de hardware correspondientes. Para identificar posibles cuellos de botella, necesitamos entender cómo se lleva a cabo el intercambio de datos. La Figura 2 a continuación nos ayudará con eso:

Figura 2. Flujos de datos entre RAM y almacenamiento persistente

Obviamente, transferir datos del almacenamiento persistente a la RAM y viceversa es la operación que más tiempo consume. Crea dos flujos de datos: lectura/escritura de páginas de datos de archivos de base de datos y lectura/escritura de archivos de ordenación. Dado que puede haber varios archivos de ordenación y pueden ser bastante grandes, pueden crear una carga bastante pesada en los discos, por lo que es aconsejable dirigir estos flujos de entrada/salida a discos diferentes.

Copia de Seguridad

Firebird ofrece dos métodos de copia de seguridad: copia de seguridad verificada con la ayuda de la utilidad gbak y copia de seguridad incremental no verificada con la ayuda de la utilidad nbackup.

Recomendamos que combine estos métodos de copia de seguridad: ejecute nbackup con frecuencia (por ejemplo, cada hora, día y semana) y cree una copia de seguridad verificada cada noche con la ayuda de gbak.

Cualquiera que sea el método de copia de seguridad que utilice, el archivo de base de datos se lee (total o parcialmente) y se escribe la copia de seguridad (completa o incremental). Las operaciones de escritura se realizan secuencialmente durante el proceso de copia de seguridad, lo que significa que los discos duros regulares y económicos con interfaz SATA (HDD SATA) serán buenos para la copia de seguridad, ya que escriben secuencialmente bastante rápido.

Selección del Hardware Adecuado

Ahora que tenemos la idea de cómo Firebird interactúa con el hardware, debemos detenernos en los factores que afectan la elección de cada componente en particular y sus especificaciones.

A veces, las estadísticas reales de una base de datos en particular afectan fuertemente la elección de los componentes de hardware, por lo que utilizaremos herramientas de HQbird (el paquete de distribución profesional de Firebird de IBSurgeon) para obtener estas estadísticas. Puede descargar la versión de prueba de HQbird en http://hqbird.com/en/hqbird/.

CPU

Al elegir la CPU, debe tener en cuenta las siguientes tres cosas:

Qué consultas prevalecen en la aplicación,
El número de conexiones activas a la base de datos en promedio y bajo cargas máximas,
La versión y arquitectura de Firebird.

¿Qué Consultas Prevalecen en la Aplicación?

Firebird siempre ejecuta una consulta en un núcleo, por lo que las consultas complejas y mal optimizadas pueden usar un núcleo hasta el 100%, forzando a otras consultas a núcleos menos cargados, y cuantos más núcleos haya, menores serán las posibilidades de que se utilice toda la CPU y de que los usuarios noten cualquier degradación del rendimiento en la aplicación.

Si la aplicación ejecuta principalmente consultas SQL simples y cortas, todas las consultas están bien optimizadas y no se generan consultas ad hoc (por ejemplo, para informes), la CPU no presentará un cuello de botella para el rendimiento y puede elegir una CPU de gama baja con menos núcleos.

Si la aplicación contiene un generador de informes o muchas consultas lentas que devuelven una gran cantidad de datos, necesita una CPU con más núcleos.

El Número de Conexiones Activas a la Base de Datos en Promedio y bajo Cargas Máximas

El número de conexiones (usuarios activos) también influye en la elección de la CPU. Desafortunadamente, incluso los desarrolladores de aplicaciones no tienen idea exacta de cuántas conexiones, consultas y transacciones están activas en un momento particular. Para obtener información más precisa sobre esto, recomendamos que utilice la herramienta MON$ Logger de HQbird y tome algunas instantáneas mientras se ejecuta, donde verá cuántas conexiones están realmente establecidas.

Figura 3. MON$ Logger: número de conexiones

Por ejemplo, aquí puede ver que el número de conexiones es 296. Obviamente, es demasiado optimista usar una CPU de cuatro núcleos en este caso, mientras que una solución de 24 núcleos será bastante adecuada. También es aconsejable contar el número de consultas que se ejecutan simultáneamente, ya que las conexiones pueden estar inactivas sin consultas SQL en ejecución.

Puede usar la tasa de 10 a 30 conexiones por núcleo para estimar aproximadamente el número necesario de núcleos en su CPU. 10 conexiones por núcleo para una aplicación con consultas mayormente complicadas y lentas, 30 conexiones por núcleo para una aplicación con consultas mayormente simples y bien optimizadas.

Versión y Arquitectura de Firebird

Si utiliza la versión 2.5 de Firebird, tenga en cuenta que debe usar la arquitectura Classic o SuperClassic para poder distribuir el procesamiento entre varios núcleos. En la versión 2.5, la arquitectura SuperServer puede usar solo un núcleo para una base de datos, por lo que no debe usarse en sistemas que consumen muchos recursos.

En la versión 3.0 de Firebird, SuperServer, Classic y SuperClassic utilizan las características de los CPUs de múltiples núcleos. Firebird 3.0 SuperServer muestra el mejor rendimiento.

RAM

Al elegir RAM, debe prestar atención a dos cosas:

el módulo de memoria debe tener código de corrección de errores (RAM ECC)
la cantidad de RAM debe calcularse correctamente

RAM ECC

La RAM ECC reduce considerablemente el número de errores que ocurren en el curso del trabajo con memoria y se recomienda encarecidamente usarla en sistemas industriales.

Cálculo de la Cantidad de RAM Necesaria

Para calcular la cantidad de memoria, tendremos que analizar las peculiaridades de las distintas arquitecturas de Firebird. Firebird 2.5 Classic y Firebird 3.0 Classic ejecutan un proceso separado para atender cada conexión, SuperClassic ejecuta un hilo separado para cada conexión, pero prácticamente con la misma estructura de consumo de memoria: cada conexión tiene su propia caché de páginas independiente.

Firebird SuperServer ejecuta un solo proceso con una caché de páginas para todas las conexiones.

Por lo tanto, los siguientes parámetros afectan el consumo general de memoria:

Número de conexiones
Tamaño de página de la base de datos
Tamaño de los metadatos (proporcional al número de tablas, disparadores, procedimientos almacenados, etc.; no ajustable; determinado por el uso físico)
Para Classic y SuperClassic - por conexión
Para SuperServer - por instancia de una base de datos abierta
Tamaño de la caché de páginas (determinado por los parámetros en el encabezado de la base de datos o en firebird.conf o en las propiedades de una conexión particular)
Para Classic y SuperClassic - por conexión
Para SuperServer - por instancia de una base de datos abierta
Tamaño de la caché de ordenamiento (determinado por el parámetro en firebird.conf). Tenga en cuenta que la memoria para el ordenamiento no se asigna de una vez, sino según sea necesario.
Para Classic - por conexión
Para SuperServer y SuperClassic - por proceso (es decir, una caché de ordenamiento)
Para Classic/SuperClassic - tamaño de la tabla de bloqueos (generalmente es pequeña, así que la dejaremos fuera de nuestro cálculo).

La empresa IBSurgeon realizó algunas pruebas y obtuvo un conjunto de valores óptimos para el número de páginas en la caché de páginas de Firebird:

Classic/SuperClassic - de 256 a 2000 páginas
SuperServer 2.5 - 10000 páginas
SuperServer 3.0 - 100000 páginas

Basándonos en estas pruebas, creamos archivos de configuración optimizados de Firebird para servidores con 4-6 GB de memoria. Puede descargarlos aquí: /es/optimized-firebird-configuration/

Fórmulas para Calcular la Cantidad de RAM Necesaria

A continuación, puede ver las fórmulas utilizadas para estimar la cantidad aproximada de memoria que requerirá Firebird. El consumo real de memoria puede diferir, ya que esta estimación no tiene en cuenta la cantidad de memoria necesaria para los metadatos, las máscaras de bits de los índices, etc., lo que puede aumentar el consumo de memoria. Sin embargo, también se supone que la memoria de ordenamiento se utilizará al máximo en todas las conexiones, lo que generalmente no es el caso.

Cuando su base de datos ya está en uso, puede observar la cantidad promedio de memoria utilizada por el proceso de Firebird (con la ayuda del Administrador de tareas o ProcessExplorer).

Estimación para Classic:

Número de conexiones * ( (Número de páginas en caché * Tamaño de página) + Tamaño de caché de ordenamiento )

Ejemplo para Classic: supongamos que esperamos 100 usuarios activos, el tamaño de página de la base de datos está configurado en 8 KB y el número de páginas en la caché de páginas está configurado en 256, el tamaño de la caché de ordenamiento se aumenta de 8 MB (el valor predeterminado para Classic y SuperClassic) a 64 MB:

((256.8 KB)+64) = 6600 MB

Estimación para SuperClassic:

Número de conexiones * (Número de páginas en caché * Tamaño de página) + Tamaño de caché de ordenamiento

Ejemplo para SuperClassic: 100 usuarios, el tamaño de página de la base de datos es 8 KB, el número de páginas en la caché de páginas es 256, el tamaño de la caché de ordenamiento es 1024 MB

100.(256.8 KB) + 1024 MB = 2024 MB

Estimación para SuperServer:

(Número de páginas en caché * Tamaño de página) + Tamaño de caché de ordenamiento

Ejemplo para SuperServer (Firebird 2.5): 1 base de datos, 100 usuarios, el tamaño de página de la base de datos es 8 KB, el número de páginas en la caché de páginas es 10000, el tamaño de la caché de ordenamiento es 1024 MB:

(10000.8 KB) + 1024 = 1102 MB

Ejemplo para SuperServer (Firebird 3.0): 1 base de datos, 100 usuarios, el tamaño de página de la base de datos es 8 KB, el número de páginas en la caché de páginas es 100000, el tamaño de la caché de ordenamiento es 1024 MB:

(100000.8 KB) + 1024 = 1805 MB

“Memoria Excesiva”

A menudo se acusa a Firebird de un uso ineficiente de la memoria: cuando el proceso en ejecución del servidor consume una pequeña cantidad de RAM y el resto de la memoria permanece supuestamente sin usar.

En realidad, esto no es cierto. Esta conclusión se basa fundamentalmente en un malentendido de cómo funciona el mecanismo de caché de Firebird y en la imperfección de las herramientas de monitoreo del sistema operativo.

En primer lugar, debe tener absolutamente claro que Firebird utiliza ampliamente la caché de archivos del sistema operativo. Cuando una página se carga en la caché de páginas de Firebird, pasa a través de la caché de archivos del sistema operativo. Cuando Firebird descarga una página de su caché de páginas, el sistema operativo mantiene este fragmento de la base de datos en su RAM siempre que tenga suficiente memoria libre.

Figura 4. Niveles de caché: Firebird, SO y almacenamiento

Sin embargo, si solo lo observa, el sistema operativo no muestra la memoria asignada a la caché de archivos como utilizada. Por ejemplo, esta es la situación típica de distribución de memoria cuando el servidor Firebird está en ejecución, como lo muestra el Administrador de tareas:

Figura 5. El Administrador de tareas no muestra el uso de la caché de archivos

Parece que solo se usan 6.3 GB de 16 GB.

Sin embargo, si utiliza la herramienta RAMMap (de SysInternals de Microsoft), todo parece mucho más lógico:

Figura 6. RAMMap muestra detalles sobre el uso de memoria: los archivos asignados son bases de datos en caché

Los archivos de base de datos (dbw350.fb252x64.fdb y dbw250.fb252x64.fdb) están en caché por el sistema operativo y ocupan toda la memoria que el Administrador de tareas declara como libre:

Figura 7. RAMMap: detalles sobre el uso de la caché de archivos

Por lo tanto, concluimos que el sistema operativo utiliza eficazmente toda la memoria disponible para almacenar en caché la base de datos hasta cargar completamente la base de datos en memoria.

Subsistema de Disco

La configuración correcta del subsistema de disco juega un papel importante en la elección y configuración del hardware para Firebird, porque cualquier error en este paso resultará en fallas importantes que son difíciles de corregir.

Discos Separados para Todo

Para reducir la competencia por la entrada/salida de disco entre las operaciones con el archivo de base de datos y disminuir las posibilidades de pérdida simultánea de la base de datos y la copia de seguridad, se recomienda tener tres discos diferentes (o conjuntos RAID): uno para la base de datos, uno para archivos temporales y uno para crear y almacenar copias de seguridad.

Cuando decimos “discos separados”, significa que los flujos de datos deben pasar por diferentes canales de entrada/salida. Si crea tres discos lógicos en un disco físico, no habrá aumento en el rendimiento. Sin embargo, si organiza tres discos lógicos en un dispositivo de almacenamiento equipado con controladores multicanal, es muy probable que el rendimiento aumente porque el dispositivo puede distribuir los flujos de datos entre los controladores. A veces se dice que dedicar un disco separado para almacenar los archivos del sistema operativo y el archivo de intercambio del sistema operativo aumenta el rendimiento.

SSD para una Base de Datos

El SSD es la mejor opción para trabajar con una base de datos porque garantiza una gran escalabilidad durante la entrada/salida paralela. Es imprescindible que utilice discos empresariales con un mayor número de ciclos de lectura/escritura; de lo contrario, es muy posible que pierda datos debido a una falla del SSD.

Hace algún tiempo, los SSD eran propensos a un mayor desgaste cuando quedaba poco espacio libre en el disco (menos del 30%). En pocas palabras, cada modificación en un SSD se escribe en una nueva celda libre, por lo que la falta de espacio libre conducía a un mayor desgaste de las celdas que permanecían libres y a una vida útil más corta del disco.

Los fabricantes de controladores SSD modernos declaran que este problema se resolvió moviendo preventivamente los datos estáticos y ahora el desgaste de las celdas está más o menos nivelado. Sin embargo, las especificaciones exactas y los algoritmos de operación de los SSD se mantienen en secreto por los fabricantes, por lo que aún recomendamos que deje un 30% de espacio libre en los SSD, así como reducir su vida útil esperada y planificar reemplazarlos no menos de una vez cada tres años.

Supongamos que el tamaño de su base de datos es actualmente de 100 GB y crece 1 GB por mes. En este caso, no debe comprar un SSD de tamaño mínimo (120 GB), sino que es mejor elegir el siguiente dispositivo en la línea de productos: 250 GB. Al mismo tiempo, comprar un SSD de 512 gigabytes será un desperdicio de dinero, ya que es recomendable reemplazar el disco en tres años.

La mejor práctica es dedicar un SSD exclusivamente a trabajar con la base de datos, ya que cualquier operación de entrada/salida reduce la vida útil de los discos.

Disco para Archivos Temporales

Dado que los archivos temporales aparecen en el disco solo cuando no hay suficiente cantidad de RAM, la mejor manera es, por supuesto, evitar esta situación por completo. Es posible evaluar el número y tamaño de los archivos temporales en un sistema de producción solo monitoreando la carpeta con archivos temporales. FBDataGuard del paquete de distribución HQbird realiza ese tipo de monitoreo. Una vez que sepa cuántos archivos de ordenamiento temporales se crean en el disco y cuándo se crean, podrá aumentar la cantidad de RAM y cambiar la configuración en firebird.conf.

En cualquier caso, Firebird requiere que especifique la carpeta donde se almacenarán los archivos temporales. Generalmente, se deja el valor predeterminado sin cambios, es decir, se utiliza la carpeta del sistema operativo para archivos temporales. Si la RAM libre es suficiente, esta es una buena opción.

Sin embargo, hay otro problema importante con respecto a la ubicación de los archivos temporales en el disco: la creación de índices al restaurar una copia de seguridad verificada (creada con la utilidad gbak). Cuando se crea un índice, también se crea un archivo temporal que contiene todas las claves de este índice. Si la base de datos es bastante grande, el tamaño del índice para alguna tabla grande también puede ser bastante grande. Por ejemplo, el índice de la tabla más grande que comprende 3.2 mil millones de registros en una base de datos de 1 terabyte es de 29 GB, pero se necesitaron 180 GB de espacio libre para crear este índice:

Para evitar la falta de espacio libre en el disco del sistema, es posible especificar un disco más como espacio reservado adicional en firebird.conf:

TempDirectories =C:\temp; H:\Temp

Si no hay espacio en el primer disco, Firebird continuará usando el segundo disco para archivos temporales y así sucesivamente.

HDD para Copias de Seguridad

Los HDD regulares con interfaz SATA o nSAS serán adecuados para crear y almacenar copias de seguridad. Garantizan operaciones rápidas de escritura y lectura secuencial para archivos de copia de seguridad y son lo suficientemente económicos como para no escatimar en su tamaño y mantener varias copias de seguridad.

Los discos para copias de seguridad siempre deben tener espacio libre adicional: el tamaño de la última copia de seguridad + 10%. En este caso, es posible crear una nueva copia de seguridad, asegurarse de que el proceso de copia de seguridad haya finalizado con éxito (este proceso puede llevar varias horas para una base de datos con un tamaño de varios terabytes) y solo después eliminar la copia de seguridad anterior.

Si elimina la copia de seguridad anterior antes de que se cree la nueva, es posible que no se cree ninguna copia de seguridad nueva mientras la anterior ya se haya eliminado y la base de datos se corrompa, por ejemplo, debido a una falla del disco.

Si utiliza el método de copia de seguridad recomendado anteriormente (la combinación de copia de seguridad incremental de tres niveles y copia de seguridad verificada una vez al día que almacena solo una copia más reciente), use la siguiente fórmula para calcular el espacio mínimo para la copia de seguridad:

Tamaño_de_base_de_datos*3+0.2.Tamaño_de_base_de_datos

Consideremos el siguiente cálculo de muestra del espacio necesario para la copia de seguridad:

Supongamos que tenemos una base de datos de 100 GB para la cual almacenamos una copia de seguridad incremental de tres niveles (semana-día-hora: una copia de cada uno) y una copia de la copia de seguridad verificada diaria. En este caso, las copias de seguridad ocuparán el siguiente espacio:

Nbackup_level_0.weekly - 100 GB
Nbackup_level_1.daily - 5 GB (aproximadamente)
Nbackup_level_2.hourly - 200 MB (aproximadamente)
Copia de seguridad verificada diaria - 100 GB (aproximadamente)
Además, necesita 110 GB reservados para poder crear la siguiente copia de seguridad.

Total - 316 GB.

! el tamaño del archivo incremental de primer nivel o superior depende del número de páginas modificadas desde la última vez que se ejecutó nbackup. El tamaño de estos archivos solo puede determinarse experimentalmente, ya que la cantidad de cambios en una base de datos depende de las aplicaciones.

Por supuesto, la estimación del espacio para la copia de seguridad debe tener en cuenta el posible aumento anormal del tamaño de la base de datos y, en consecuencia, aumentar la cantidad de espacio libre; de lo contrario, el proceso de copia de seguridad puede interrumpirse inesperadamente debido a la falta de espacio.

Naturalmente, las herramientas inteligentes de copia de seguridad (FBDataGuard de HQbird) detectarán la falta de espacio para las copias de seguridad y enviarán el mensaje correspondiente al administrador.

Disco duro para una base de datos

Un SSD puede resultar una solución demasiado cara, o la base de datos puede ser demasiado grande y tendrá que utilizar métodos menos costosos. En este caso, debe utilizar un disco duro con interfaz SAS. Si no es posible, use discos SATA con interfaz nSAS o la opción más económica: discos SATA normales.

Para aumentar la velocidad (y también la fiabilidad, como se verá más adelante) de los discos duros, debe combinarlos en RAID10. RAID10 es una combinación de bloques en espejo (RAID1) y en franjas (RAID0). Un buen controlador RAID bien configurado con una gran caché es una buena alternativa a los SSD.

Fiabilidad y RAID

Por supuesto, es necesario aumentar la fiabilidad del subsistema de discos combinando los discos en RAID en todas las variantes mencionadas anteriormente (excepto el disco dedicado exclusivamente a archivos temporales).

• Para SSD, asegúrese de utilizar RAID1, es decir, dos discos en espejo en los que los cambios se escriben simultáneamente, lo que reduce considerablemente las posibilidades de perder todos los datos. RAID 10 compuesto por SSD probablemente será redundante, ya que el bus RAID limitará el rendimiento. Por ejemplo, la interfaz de 6 Gbit/s tiene un rendimiento de 600 megabytes por segundo, mientras que los SSD individuales modernos ya han alcanzado esta velocidad. Así, obtendremos el mismo límite de 600 MB/s para RAID 10.

Excepto que puede usar PCI Express 3.0 para combinar SSD en RAID 10, porque el rendimiento de este bus ya es de 16 gigabits por segundo o más.

• Si utiliza discos duros para fines de copia de seguridad, es suficiente usar RAID1, que garantizará la seguridad de las copias de seguridad y una velocidad de lectura y escritura aceptable.

• Los discos duros utilizados para una base de datos deben combinarse en RAID10 (al menos 4 discos), que proporcionan la combinación óptima de costo, fiabilidad y rendimiento. Algunos usuarios también usan RAID5 sacrificando rendimiento por más espacio.

Configuración RAID para Firebird

En primer lugar, debe asegurarse de que haya una unidad de batería de respaldo (BBU) correctamente cargada en el RAID. Si no hay tal unidad de batería, la mayoría de los RAID cambian al modo de escritura segura (la caché del disco está completamente deshabilitada), lo que proporciona una velocidad de entrada/salida más baja que un disco SATA normal.

Este hecho causa la mayoría de los mensajes frustrados al soporte técnico de usuarios que han comprado un servidor caro y descubren que funciona más lento que una computadora de escritorio. Desafortunadamente, algunos proveedores no incluyen unidades de batería por defecto, por lo que es lo primero que debe verificar y corregir, si es necesario.

Luego debe configurar la caché de lectura y escritura. A menudo, la caché está deshabilitada por defecto y si desea que RAID sea bastante rápido, debe habilitarla.

Además de habilitar la caché, debe verificar cómo funciona: puede ser write through (escritura directa) y write back (escritura diferida). La forma rápida de trabajar con la caché es write back; en este caso, cualquier cambio se escribe en el controlador de caché y, después de un tiempo, directamente al disco.

Puede usar las herramientas de los fabricantes suministradas con RAID para verificar la unidad de batería, la caché y el modo.

Los controladores RAID modernos también pueden ajustar finamente la caché: se puede modificar para facilitar la lectura o la escritura. Generalmente, se divide 50%/50% para lectura y escritura.

Para saber exactamente cómo configurar la caché, también puede usar la herramienta MON$ Logger del paquete de distribución avanzado de HQbird. Muestra la proporción de operaciones de lectura y escritura entre sí (agregadas desde el momento de la primera conexión al servidor):

Figura 8. HQbird MON$Logger: proporción de lectura/escritura

Como puede ver, hay muchas más operaciones de lectura que de escritura en este ejemplo, por lo que tiene sentido configurar el controlador RAID para un 80% de operaciones de lectura y un 20% de operaciones de escritura.

SAN y bases de datos

Los almacenamientos integrados se han vuelto populares recientemente. Incluyen una matriz de discos flexiblemente personalizable (todos los tipos de RAID) con funciones avanzadas de caché. Generalmente, los SAN tienen varios controladores de entrada/salida, lo que permite atender a varios servidores simultáneamente y trabajar bastante rápido.

Muchas organizaciones compran SAN y los usan en su trabajo con bases de datos Firebird. Si un SAN está configurado correctamente, es posible lograr un buen rendimiento. Debe tener en cuenta los siguientes problemas si usa SAN:

Deben estar disponibles varios controladores de disco de alto rendimiento que proporcionen un intercambio de datos multicanal.
Deben estar presentes las unidades de batería de respaldo (BBU) si están previstas por diseño.
Los discos de la base de datos deben combinarse en RAID10.
La caché debe estar habilitada y el modo de escritura debe cambiarse a write back.
Si varios equipos están conectados al SAN, cada uno debe tener su propio controlador.
Los controladores SAN más recientes están instalados. Hemos encontrado casos en los que los controladores posteriores proporcionaron un aumento del 30% en el rendimiento.
Si hay varios discos lógicos en un SAN (para bases de datos, copias de seguridad, sistema operativo), tienen diferentes canales de entrada/salida. Intentar usar un solo canal para todos los discos en conjunto resultará en un rendimiento menor.
De manera similar, si varios servidores y bases de datos usan un SAN al mismo tiempo, el rendimiento puede ser menor debido al mayor ancho de banda de los controladores de entrada/salida.
A menudo se usan formas combinadas: cuando el sistema operativo y los archivos temporales se almacenan en discos locales, mientras que la base de datos y los archivos de copia de seguridad se almacenan en un SAN.

A menudo, los SAN se usan como “dos servidores - un SAN” para crear un clúster a prueba de fallos. Debe tenerse en cuenta que dicho clúster solo puede resolver problemas relacionados con fallas de hardware en uno de los servidores cambiando al segundo servidor de inmediato. Si el problema está relacionado con el SAN o con la propia base de datos, esta solución no ayudará.

Para construir una solución realmente a prueba de fallos, debe usar soluciones que repliquen datos entre dos instancias de base de datos. Puede contactar a [email protected] para conocer más soluciones disponibles para Firebird.

Breves conclusiones y recomendaciones

Resumamos las conclusiones y recomendaciones para Firebird en cuanto al hardware.

Se deben usar CPU multinúcleo para atender a un gran número de usuarios.
La cantidad mínima de RAM se calcula en función del número de usuarios y la configuración de la base de datos; el exceso de RAM será utilizado eficazmente por el sistema operativo para almacenar en caché el archivo de la base de datos.
Use discos separados para bases de datos, archivos temporales y archivos de copia de seguridad.
Prefiera usar SSD para bases de datos.
Reserve al menos un 30% de espacio libre en los SSD.
Es recomendable dedicar un disco a la base de datos.
Use SSD empresariales (con muchos ciclos de escritura/lectura).
Asegúrese de usar RAID.
Para SSD - RAID 1, para HDD - RAID10, para HDD de copia de seguridad - RAID1. i. SAS, SATA, nSAS
Asegúrese de que la batería RAID esté presente y cargada.
Asegúrese de que esté cambiado a write back.
Algunos controladores RAID ya tienen el tamaño de caché configurado, por ejemplo, 75% para lectura, 25% para escritura, o 50/50, etc. Por lo tanto, es necesario instalar MON$Logger: el software que controlará los parámetros RAID, buscará la proporción de lectura/escritura y cambiará la configuración RAID.
Hay pros y contras en el uso de SAN. Para aprovecharlo al máximo, debe configurar el SAN correctamente.
Para construir una solución a prueba de fallos, necesita usar soluciones con réplicas que se ejecuten en diferentes servidores.

Contactos

La empresa IBSurgeon/IBase.ru ha estado desarrollando un paquete de distribución avanzado de HQbird para empresas, proporcionando soporte técnico complejo para Firebird y desarrollando paquetes de distribución personalizados, así como resolviendo otros problemas complicados.

IBSurgeon también ofrece el servicio de Optimización de Firebird para mejorar el rendimiento de las bases de datos Firebird.

Contáctenos: [email protected]