architecture - que - snapshot aws

¿Práctica recomendada para implementar MongoDB en EC2 para producción?

Question

Me gustaría implementar mongoDB en EC2 para mi producción. Sin embargo, no pude encontrar suficiente información en línea para ayudar a responder mis preguntas sobre arquitectura.

1. En general, ¿cuál debería ser el clúster inicial con fragmentos N?
2. ¿Cuál debería ser el plan de despliegue para agregar fragmentos adicionales?
3. ¿Cuál debería ser la estrategia de conmutación por error (lo que ocurre cuando fallan uno o más nodos)?
4. ¿Cuál debería ser la estrategia de recuperación de desastres? Estoy pensando en configurar algunos nodos en el este de los EE. UU. Y otros nodos en el oeste de EE. UU., Como dice este archivo de PowerPoint .

Las respuestas son muy apreciadas.

Answer 1

1. Comience con el sharding habilitado pero limite la cantidad de fragmentos a lo que realmente necesita. Comenzar con sharding habilitado significa tener demonios de mongos en su lugar, seleccionar sus claves de fragmentos para las colecciones relevantes y hacer que sus consultas sean dirigidas en lugar de global siempre que sea posible. A partir de ese momento, agregue los fragmentos a medida que aumenta la carga. La posible excepción es cuando espera una gran afluencia de tráfico en el lanzamiento, en cuyo caso desea agregar más fragmentos y dividir previamente y mover previamente sus fragmentos a los fragmentos apropiados, ya que el balanceo de fragmentos es un proceso lento.
2. Ningún plan es necesario. Los fragmentos se pueden agregar y eliminar al vuelo. Tenga en cuenta que eliminar los fragmentos implica retirarlos. A partir de ese punto, pasará una cantidad (significativa) de tiempo antes de que todos los fragmentos se muevan a otros fragmentos para que la instancia pueda eliminarse.
3. Los conjuntos de réplica permiten esto. Si sus requisitos de durabilidad no son súper críticos, puede lograr una cierta rentabilidad al hospedar múltiples árbitros en una sola instancia en lugar de hacer repuestos completos de 3 miembros. También tenga en cuenta que los repsets mejorarán el rendimiento de lectura para eventuales consultas compatibles con la coherencia usando el indicador "slaveOk". Además, puede considerar alcanzar niveles similares de durabilidad con menos sobrecarga mediante la conmutación por error de nivel de disco (por ejemplo, RAID10). Obviamente, esto no atrapa fallas de instancia completa.
4. Las divisiones geográficas del centro de datos siempre son una buena idea, pero tenga en cuenta que el rendimiento de replicación sufrirá significativamente. Las estrategias para esto no son diferentes de cualquier otra base de datos.

Notas adicionales:

• La capa de red EC2 está limitada a 100k paquetes por segundo. Para consultas pequeñas y de alto rendimiento, esto se convertirá rápidamente en un cuello de botella.
• RAID sus volúmenes de EBS. Ejecutar en un solo volumen de EBS causará un rendimiento EXTREMADAMENTE irratico. Esto se vuelve más estable a medida que más volúmenes forman parte de la configuración RAID. ¡Debe tener!
• Usa instancias de memoria alta. Hemos visto importantes mejoras en el rendimiento aquí, ya que hay mucho que puede hacer para equilibrar correctamente sus índices y mantener solo los datos relevantes en la memoria. Vigila tus fallas / seg en mongostat. Estos son los defectos de página y, por lo tanto, la cantidad de veces que mongo debe presionar el disco para cambiar una página.

Answer 2

1) Comenzaría con un par de fragmentos a menos que sepa que definitivamente necesita más.
2) La parte difícil de agregar más fragmentos es el tiempo que lleva reequilibrar. Dependiendo de sus datos y la carga, puede llevar días volver a equilibrar todo el fragmento. Así que desea programar la adición del fragmento durante tiempos de baja carga
3) Cada fragmento debe ser al menos un conjunto de réplicas 2 + 1 con las réplicas distribuidas en las zonas de disponibilidad.
4) Si está interesado en la recuperación de desastres, debe distribuir sus réplicas entre las regiones en lugar de en las zonas de disponibilidad. Más información aquí - Mejores prácticas de EC2 . Recuerde también configurar correctamente la prioridad de sus conjuntos de réplicas en caso de que distribuya las réplicas en distintas ubicaciones geográficas.

Answer 3

Winston, "Scaling MongoDB" de Kristina Chodorow es lo que quieres:

http://oreilly.com/catalog/0636920018308

Como yo lo entiendo,

1) Desea conjuntos de réplicas de 3 o más (algunos números impares) instancias para cada fragmento, más tal vez algunas instancias con retardo de tiempo en cada fragmento para actuar como respaldo

2) Simplemente agréguelos al clúster: Mongo moverá lentamente los fragmentos a los nuevos nodos hasta que el clúster haya sido reequilibrado

3) Los conjuntos de réplica generalmente manejarán la conmutación por error muy bien; sin embargo, es posible que desee agregar instancias de árbitro de Mongo a los servidores que ejecutan su interfaz de aplicación; estos árbitros votarán por que las instancias restantes se vuelvan primarias, en el caso de que haya muchos nodos, y ayudarán a garantizar que cualquier instancia de Mongo accesible sus servidores frontend serán capaces de asumir roles principales

4) Agregar instancias con retardo de tiempo para cada conjunto de réplicas es una buena idea, especialmente si (como dices) están distribuidas geográficamente, o si están en varios proveedores de hosting (es decir, si tus servidores principales están en Amazon, podría poner copias de seguridad en Rackspace). Si la mayoría de un conjunto de réplicas baja, los nodos restantes no elegirán automáticamente un nuevo primario, pero puede hacerlo manualmente en un desastre como ese.

Answer 4

myNoSQL, mi blog NoSQL más favorito, publicó recientemente un artículo llamado Running MongoDB en la nube que enumera varios artículos sobre la implementación de MongoDB en la nube de Amazon.

• MongoDB en Amazon EC2 con volúmenes de EBS
• MongoDB en EC2
• MongoDB en la nube de Amazon
• Configuración de conjuntos de réplica MongoDB en Amazon EC2
• MongoDB y Amazon: ¿Por qué EBS?
• Amazon EBS vs SSD: precio, rendimiento, calidad de servicio
• Desempeño de almacenamiento multi-tenancy y en la nube