Para obtener una descripción general de AlloyDB Omni, consulta Descripción general de AlloyDB Omni.
Tamaño y capacidad
El tamaño y la capacidad afectan directamente el rendimiento, la confiabilidad y la rentabilidad de tu instancia de AlloyDB Omni. Cuando migras una base de datos existente, los recursos de CPU y memoria necesarios son similares a los requisitos del sistema de base de datos de origen.
Planifica comenzar con una implementación que use recursos de CPU, RAM y disco coincidentes, y usa la configuración del sistema de origen como la configuración de referencia de AlloyDB Omni. Es posible que puedas reducir el consumo de recursos después de realizar suficientes pruebas de tu instancia de AlloyDB Omni.
El dimensionamiento de un entorno de AlloyDB Omni incluye los siguientes pasos:
Define tu carga de trabajo.
Volumen de datos: Estima la cantidad total de datos que almacenarás en AlloyDB Omni. Ten en cuenta los datos actuales y el crecimiento proyectado a lo largo del tiempo.
Tasa de transacciones: Determina la cantidad esperada de transacciones por segundo (TPS), incluidas las lecturas, escrituras, actualizaciones y eliminaciones.
Simultaneidad: Estima la cantidad de usuarios o conexiones simultáneos que acceden a la base de datos.
Requisitos de rendimiento: Define los tiempos de respuesta aceptables para diferentes tipos de consultas y operaciones.
Asegúrate de que tu hardware admita los requisitos de tamaño.
CPU: AlloyDB Omni se beneficia de los sistemas con varios núcleos de CPU y se ajusta de forma lineal, según la carga de trabajo. Sin embargo, PostgreSQL de código abierto generalmente no se beneficia de más de 16 CPU virtuales. Ten en cuenta lo siguiente:
- La cantidad de núcleos según la simultaneidad y las necesidades de procesamiento de la carga de trabajo
- Las ganancias que puedan estar presentes debido a un cambio en la generación o la plataforma de la CPU
Memoria: Asigna suficiente RAM a los búferes compartidos de AlloyDB Omni para almacenar en caché los datos y la memoria de trabajo para el procesamiento de consultas. El requisito exacto depende de la carga de trabajo. Comienza con 8 GB de RAM por CPU virtual.
Almacenamiento
Tipo: Según tus necesidades, elige entre el almacenamiento NVMe local para obtener rendimiento o el almacenamiento SAN para lograr escalabilidad y uso compartido de datos.
Capacidad: Asegúrate de tener suficiente almacenamiento para el volumen de datos, los índices, el registro de escritura anticipada (WAL), las copias de seguridad y el crecimiento futuro.
IOPS: Estima las operaciones de entrada y salida por segundo (IOPS) necesarias según los patrones de lectura y escritura de tu carga de trabajo. Cuando ejecutes AlloyDB Omni en una nube pública, considera las características de rendimiento de tu tipo de almacenamiento para comprender si necesitas aumentar la capacidad de almacenamiento y alcanzar un objetivo específico de IOPS.
Requisitos previos para ejecutar AlloyDB Omni
Antes de ejecutar AlloyDB Omni, asegúrate de cumplir con los siguientes requisitos de hardware y software.
Requisitos de hardware
Los requisitos del sistema para la pila de implementación de AlloyDB Omni incluyen un nodo preconfigurado para ejecutar varios componentes. El nodo de AlloyDB Omni debe tener un disco de datos adjunto configurado con el sistema de archivos ext4/xfs, con un tamaño que se estima a partir del tamaño de los datos. Las características de rendimiento del almacenamiento afectan el rendimiento de AlloyDB Omni.
| Nodo | Hardware mínimo | Hardware recomendado |
|---|---|---|
| AlloyDB Omni |
|
|
- Te recomendamos que uses un dispositivo de almacenamiento de unidad de estado sólido (SSD) exclusivo para almacenar tus datos. Si usas un dispositivo físico para este propósito, te recomendamos que lo conectes directamente a la máquina anfitrión.
Requisitos de software
| SO/Plataforma | Software mínimo |
|---|---|
| Linux1 |
|
-
AlloyDB Omni supone que el paquete
policycoreutils-python-utilsestá instalado antes de instalar el paquete RPM de AlloyDB Omni. Esto permite que AlloyDB Omni configure la política de SELinux que permite que se ejecute el servicio de base de datos de AlloyDB Omni.
Tipos de almacenamiento admitidos
AlloyDB Omni admite sistemas de archivos en volúmenes de almacenamiento en bloque en instancias de bases de datos. Para sistemas de prueba o desarrollo más pequeños, usa el sistema de archivos local del host en el que se ejecuta el contenedor. Para las cargas de trabajo empresariales, usa el almacenamiento reservado para las instancias de AlloyDB Omni. Según las exigencias establecidas por la carga de trabajo de tu base de datos, configura tus dispositivos de almacenamiento en una configuración singleton con un dispositivo de disco para cada contenedor o en una configuración consolidada en la que varios contenedores leen y escriben desde el mismo dispositivo de disco.
Almacenamiento local NVMe o SAN
Tanto el almacenamiento local Non-Volatile Memory Express (NVMe) como el almacenamiento de red de área de almacenamiento (SAN) ofrecen ventajas distintas. Elegir la solución adecuada depende de los requisitos específicos de tu carga de trabajo, tu presupuesto y tus necesidades de escalabilidad futuras.
Para determinar la mejor opción de almacenamiento, considera lo siguiente:
- Para priorizar el rendimiento absoluto, elige NVMe local.
- Si necesitas almacenamiento compartido a gran escala, elige SAN.
- Si necesitas equilibrar el rendimiento y el uso compartido, considera usar una SAN con NVMe a través de Fabrics para un acceso más rápido.
Almacenamiento local NVMe
NVMe es un protocolo de alto rendimiento diseñado para unidades de estado sólido (SSD). Para las aplicaciones que necesitan acceso rápido a los datos, el almacenamiento NVMe local ofrece los siguientes beneficios:
- Las unidades SSD NVMe se conectan directamente al bus de interconexión de componentes periféricos express (PCIe) para ofrecer velocidades de lectura y escritura rápidas.
- El almacenamiento NVMe local proporciona la latencia más baja.
- El almacenamiento NVMe local proporciona la mayor capacidad de procesamiento.
Para escalar el almacenamiento NVMe local, es necesario agregar más unidades a los servidores individuales. Sin embargo, agregar más unidades a servidores individuales genera grupos de almacenamiento fragmentados y posibles complejidades de administración. El almacenamiento NVMe local no está diseñado para compartir datos entre varios servidores. Dado que el almacenamiento NVMe local es local, los administradores de servidores deben protegerse contra las fallas de disco con un conjunto redundante de discos económicos (RAID) de hardware o software. De lo contrario, la falla de un solo dispositivo NVMe provocará la pérdida de datos.
Almacenamiento SAN
Una SAN es una red de almacenamiento dedicada que conecta varios servidores a un grupo compartido de dispositivos de almacenamiento, a menudo SSDs o almacenamiento NVMe centralizado. Si bien la SAN no es tan rápida como la NVMe local, las SAN modernas, en especial las que usan NVMe over Fabrics, siguen ofreciendo un rendimiento excelente para la mayoría de las cargas de trabajo empresariales.
Las SAN son altamente escalables. Para agregar más capacidad de almacenamiento o rendimiento, agrega nuevos arrays de almacenamiento o actualiza los existentes. Las SAN proporcionan redundancia en la capa de almacenamiento, lo que brinda protección contra fallas en los medios de almacenamiento.
Las SAN son excelentes para el uso compartido de datos. En el caso de los entornos empresariales que requieren alta disponibilidad, varios servidores pueden acceder a los datos almacenados en la SAN y compartirlos. En caso de falla del servidor, puedes presentar el almacenamiento SAN a otro servidor del centro de datos, lo que permite una recuperación más rápida.