Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Pilar de fiabilidad
El [pilar de la confiabilidad](https://docs.aws.amazon.com/wellarchitected/latest/framework/reliability.html) abarca la capacidad de una carga de trabajo para realizar su función prevista de manera correcta y consistente cuando se espera que lo haga. Esto incluye la capacidad de utilizar y probar la carga de trabajo a lo largo de todo su ciclo de vida.
Una carga de trabajo fiable comienza por tomar decisiones de diseño anticipadas tanto para el software como para la infraestructura. Sus elecciones de arquitectura afectarán al comportamiento de su carga de trabajo en todos los pilares de AWS Well-Architected. Para la fiabilidad, debe seguir patrones específicos.
El pilar de fiabilidad se centra en las siguientes áreas clave:
+ Arquitectura de la carga de trabajo, lo que abarca las cuotas de servicio y los patrones de implementación
+ Administración de cambios
+ Administración de errores
## Cuotas de servicio de Neptune
El [volumen de un clúster de Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/feature-overview-storage.html) puede crecer hasta un tamaño máximo de 128 tebibytes (TiB) en todos los Regiones de AWS casos admitidos, excepto en China GovCloud y, donde la cuota es de 64 TiB.
La cuota de 128 TiB es suficiente para almacenar aproximadamente entre 200 000 y 400 000 millones de objetos en el gráfico. En un gráfico de propiedades etiquetadas (LPG), un [objeto](https://docs.aws.amazon.com/neptune/latest/userguide/graph-get-started.html) es un nodo, una arista o una propiedad de un nodo o arista. En un gráfico del marco de descripción de recursos (RDF), un objeto es un [quad](https://docs.aws.amazon.com/neptune/latest/userguide/feature-overview-data-model.html).
Para cualquier [clúster Neptune Serverless](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-serverless-capacity-scaling.html), debe establecer el número mínimo y máximo de unidades de capacidad de Neptune (). NCUs Cada NCU consta de 2 gibibytes (GiB) de memoria y la vCPU y las redes asociadas. Los mismos valores mínimos y máximos de NCU se aplican a cualquiera de las instancias sin servidor del clúster. El valor máximo de NCU más alto que puede establecer es 128,0 NCUs y el mínimo más bajo es 1,0. NCUs Optimice el rango de NCU que mejor se adapte `NCUUtilization` a su aplicación observando las CloudWatch métricas de Amazon `ServerlessDatabaseCapacity` y capturando el rango en el que se encuentra habitualmente y correlacionando el comportamiento no deseado o los costos dentro de ese rango. En muchas cargas de trabajo, 1,0 NCU es un punto de partida demasiado bajo y provoca un comportamiento poco fiable tras períodos de inactividad. Si descubre que su carga de trabajo no se escala lo suficientemente rápido, aumente el mínimo NCUs para proporcionar suficiente procesamiento para el aumento inicial mientras se amplía.
Cada una de ellas Cuenta de AWS tiene cuotas para cada región en cuanto a la cantidad de recursos de base de datos que puede crear. Estos recursos incluyen las instancias y clústeres de base de datos. Después de que alcance el límite de un recurso, las llamadas adicionales para crear ese recurso dejan de funcionar con una excepción. Algunas cuotas son flexibles y se pueden aumentar solicitándolo. Para obtener una lista de las cuotas compartidas entre Amazon Neptune y Amazon RDS, Amazon Aurora y Amazon DocumentDB (compatible con MongoDB), junto con enlaces para solicitar aumentos de cuota cuando sea posible, consulte [Cuotas en Amazon RDS.](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html#RDS_Limits.Limits)
## Patrones de implementación de Neptune
En los clústeres de base de datos de Neptune, hay una instancia de base de datos principal y hasta 15 réplicas de Neptune. La instancia principal de base de datos admite operaciones de lectura y escritura y realiza todas las modificaciones de los datos en el volumen del clúster. Las réplicas de Neptune se conectan al mismo volumen de almacenamiento que la instancia de base de datos principal y solo admiten operaciones de lectura. Las réplicas de Neptune pueden descargar las cargas de trabajo de lectura desde la instancia de base de datos principal.
Para lograr una alta disponibilidad, utilice réplicas de lectura. Tener una o más instancias de réplica de lectura disponibles en distintas zonas de disponibilidad puede aumentar la disponibilidad, ya que las réplicas de lectura sirven como destinos de conmutación por error para la instancia principal. S la instancia principal falla, Neptune promueve una instancia de réplica de lectura para convertirla en la instancia principal. Cuando esto ocurre, se produce una breve interrupción (normalmente de menos de 30 segundos) mientras se reinicia la instancia promovida, durante la cual las solicitudes de lectura y escritura que se realizan a la instancia principal fallan con una excepción. Para obtener la máxima fiabilidad, use dos réplicas de lectura en diferentes zonas de disponibilidad. Si la instancia principal de la zona de disponibilidad 1 se desconecta, la instancia de la zona de disponibilidad 2 pasa a ser la principal, pero no podrá gestionar las consultas mientras eso suceda. Por lo tanto, se necesita una instancia en la zona de disponibilidad 3 para gestionar las consultas de lectura durante la transición.
Si utiliza Neptune sin servidor, las instancias de lectura y escritura de todas las zonas de disponibilidad se escalarán y reducirán verticalmente, independientemente unas de otras, en función de la carga de la base de datos. Puede establecer el nivel de promoción de una instancia de lectura en 0 o 1 para que se escale o reduzca verticalmente según la capacidad de la instancia de escritura. De esta forma, queda lista para asumir la carga de trabajo actual en cualquier momento.
Si su aplicación tiene una presencia mundial o requiere una [conmutación por error en varias regiones](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-gdb-disaster-recovery.html), considere la posibilidad de utilizar una base de datos global de [Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-global-database.html). Una base de datos global de Amazon Neptune abarca varias áreas Regiones de AWS, lo que permite lecturas globales de baja latencia y proporciona una recuperación rápida en el raro caso de que una interrupción afecte a una totalidad. Región de AWS Una base de datos global de Neptune consta de un clúster de base de datos principal en una región y hasta cinco clústeres de bases de datos secundarios en diferentes regiones.
## Administración y escalado de los clústeres de Neptune
Puede usar el [escalado automático de Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/manage-console-autoscaling.html) para ajustar automáticamente el número de réplicas de Neptune en un clúster de base de datos para cumplir con los requisitos de conectividad y carga de trabajo según los umbrales de uso de la CPU. Con el autoescalado, el clúster de base de datos de Neptune puede gestionar los aumentos repentinos de la carga de trabajo. Cuando la carga de trabajo se reduce, el autoescalado elimina las réplicas innecesarias para que no tenga que pagar por la capacidad no utilizada. Tenga en cuenta que el lanzamiento de una nueva instancia puede tardar hasta 15 minutos, por lo que el autoescalado por sí solo no es una solución suficiente para los cambios rápidos de la demanda.
Solo puede usar el escalado automático con un clúster de base de datos de Neptune que ya tenga una instancia de escritura principal y al menos una instancia de réplica de lectura (consulte [Amazon Neptune DB Clusters and Instances](https://docs.aws.amazon.com/neptune/latest/userguide/feature-overview-db-clusters.html)). Además, todas las instancias de réplica de lectura del clúster deben estar en un estado disponible. Si alguna réplica de lectura está en un estado distinto a disponible, el escalado automático de Neptune no hace nada hasta que estén disponibles todas las réplicas de lectura del clúster.
Si experimenta cambios rápidos en la demanda, considere la posibilidad de utilizar instancias sin servidor. Las instancias sin servidor se pueden escalar verticalmente durante periodos cortos, mientras que el autoescalado escala horizontalmente durante periodos más largos. Esta configuración proporciona una escalabilidad óptima porque las instancias sin servidor se escalan verticalmente, mientras que el autoescalado crea instancias de nuevas réplicas de lectura para gestionar la carga de trabajo más allá de la capacidad máxima de una sola instancia sin servidor. Para obtener más información sobre el escalado de capacidad de Amazon Neptune sin servidor, consulte [Capacity scaling in a Neptune Serverless DB cluster](https://docs.aws.amazon.com/neptune/latest/userguide/neptune-serverless-capacity-scaling.html).
Si sus necesidades de escalado cambian en momentos predecibles, puede [programar cambios](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) en las instancias mínimas y máximas, así como en los umbrales para gestionar mejor esas necesidades cambiantes. Recuerde programar los eventos de escalado horizontal con al menos 15 minutos de antelación para permitir que esas instancias se pongan en funcionamiento cuando sea necesario.
Use los [parámetros](https://docs.aws.amazon.com/neptune/latest/userguide/parameter-groups.html) de un grupo de parámetros para administrar la configuración de la base de datos en Amazon Neptune. Los grupos de parámetros sirven de *contenedor* para los valores de configuración del motor que se aplican a una o varias instancias de bases de datos. Al modificar los parámetros del clúster en grupos de parámetros, debe tener en cuenta la diferencia entre los parámetros estáticos y dinámicos, y cómo y cuándo se aplican. Utilice el punto de conexión [status](https://docs.aws.amazon.com/neptune/latest/userguide/access-graph-status.html) para ver la configuración aplicada actualmente.
## Administración de copias de seguridad y eventos de conmutación por error
Neptune crea copias de seguridad del volumen de clúster automáticamente y retiene los datos de restauración durante el *periodo de retención de copia de seguridad*. Las copias de seguridad de Neptune son continuas y progresivas para que se puedan restaurar con rapidez a cualquier punto durante el periodo de retención de copia de seguridad. Puede especificar un periodo de retención de copia de seguridad de 1 a 35 días cuando cree o modifique un clúster de base de datos.
Para retener una copia de seguridad más allá del periodo de retención de copia de seguridad, también puede crear una instantánea de los datos del volumen de clúster. Al almacenar instantáneas, se generan los cargos de almacenamiento estándar para Neptune.
Cuando se crea una instantánea de Amazon Neptune de un clúster de base de datos, Neptune crea una instantánea del volumen de almacenamiento del clúster. Para ello, realiza una copia de seguridad de todos los datos, no solo de las instancias individuales. Para crear posteriormente un clúster de base de datos nuevo, restaure esa instantánea de clúster de base de datos. Al restaurar el clúster de base de datos, debe indicar el nombre de la instantánea del clúster de base de datos desde la que se restaura y, a continuación, proporcionar un nombre para el nuevo clúster de base de datos que se crea con la operación de restauración.
Pruebe cómo responde su sistema a los eventos de conmutación por error. Use la API de Neptune para [forzar un evento de conmutación por error](https://docs.aws.amazon.com/neptune/latest/apiref/API_FailoverDBCluster.html). El [reinicio con conmutación por error](https://docs.aws.amazon.com/neptune/latest/apiref/API_RebootDBInstance.html) resulta beneficioso cuando se desea simular un error en una instancia de base de datos para realizar pruebas o restaurar operaciones en la zona de disponibilidad original después de que se produzca una conmutación por error. Para obtener más información, consulte [Configuración y administración de una implementación multi-AZ para Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html). Al reiniciar una instancia de escritura de la base de datos, este conmuta por error a la réplica en espera. El reinicio de una réplica de Neptune no inicia una conmutación por error.
Diseño de los clientes para que sean fiables. Pruebe su comportamiento durante los eventos de conmutación por error. Implemente la lógica de reintento en su cliente con una lógica de retroceso exponencial. Los ejemplos de código que implementan esta lógica se encuentran en la documentación bajo los [ejemplos de AWS Lambda funciones de Amazon Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/lambda-functions-examples.html).
Considere la posibilidad de utiliza [AWS Backup](https://aws.amazon.com/blogs/storage/centralizing-data-protection-and-compliance-for-amazon-neptune-with-aws-backup/) si tiene un conjunto común de requisitos de copia de seguridad que se aplican a varios motores de bases de datos.