Necesito almacenar 25 millones de fotos en 4 tamaños = un total de 100 millones de archivos, el tamaño del archivo variará entre 3 Kb y 200 kb por archivo y el almacenamiento utilizado al principio es de aproximadamente 14 a 15 TB.
Nuestro objetivo es tener los datos en 2-4 servidores disponibles y servirlos con un servidor web local rápido (nginx o lighthttpd), necesitamos servir tantos requisitos por segundo como sea posible.
Mi plan es usar 2U Servercase de Intel con 12x2TB (WD RE4) con Raid 6 (¿o FS con redundancia?) para los datos y 2x60GB SSD para el sistema operativo, ¿es una buena manera? Ahora: encontré el Adaptec 5805ZQ que puede usar unidades SSD SLC para el caché de los archivos más usados, ¿alguna sugerencia al respecto?
¿Qué tamaño de caché de lectura debo elegir?
¿Cuál será la mejor manera de lograr redundancia y equilibrio de carga si planeo tener entre 2 y 4 servidores de este tipo?
¿Cuáles son las ventajas y desventajas entre Cluster y FS distribuidos con respecto a nuestro objetivo?
Respuesta1
Si se trata de un desarrollo totalmente nuevo, entoncesAbsolutamente usaría la nube para esto.. 100 M de archivos son muchos datos; Sería una mejora importante descargar el almacenamiento redundante para cambiar Amazon S3.
Dado que estamos hablando de archivos de 100 M, creo que podemos decir con seguridad que algunas partes del conjunto de datos estarán "calientes" (solicitadas con frecuencia) y la mayoría de las partes estarán frías. Por lo tanto, realmente queremos el almacenamiento en caché.
Una descripción general de cómo se podría hacer esto en Amazon Web Services:
- Primera capa:Elastic Load Balancing administrado por Amazon y monitoreo de Amazon CloudWatch para un par de instancias EC2 pequeñas con nginx o Apache. Estos servidores son simplemente equilibradores de carga tontos con archivos de configuración estáticos, por lo que Cloudwatch puede monitorearlos por nosotros y generar automáticamente nuevas instancias si uno de ellos falla.
- De la primera capa:Hasting consistente basado en la URL de solicitud (nombre de archivo)a una capa de servidores de caché. Desea un hash basado en el nombre del archivo para garantizar que cada archivo no se almacene en caché muchas veces (lo que reduce la tasa de aciertos de la caché), sino que con N servidores de caché cada servidor maneja 1/N del espacio de direcciones.
- Segunda capa:Servidor(es) de caché. Sus servidores de caché son instancias EC2 con más memoria, y Squid o Varnish oServidor de tráfico Apachecaché instalado.
- Desde la segunda capa: almacenamiento de archivos HTTP simple a Amazon S3.
Dado que esta configuración está débilmente acoplada,ampliarlo horizontalmente es fácil(a medida que avanzan los problemas de escala).
La velocidad que tenga dependerá en gran medida de la relación entre los datos fríos y calientes. Si su carga de trabajo es mayormente activa, entonces no me sorprendería ver muy por encima de 10,000 solicitudes/s de solo 2 pequeños EC2 de balanceador de carga y 2 instancias EC2 de caché de alta memoria.
Respuesta2
Los SSD para el sistema operativo en sí son excesivos, a menos que estés realmente interesado en arrancar 30 segundos más rápido. Simplemente consiga un par de unidades SAS pequeñas y debería ser más que suficiente.
Wrt. el caché, la utilidad del caché depende del conjunto de trabajo. Es decir, ¿se espera que las solicitudes de imágenes se distribuyan uniformemente entre todas las imágenes, o espera que la mayoría de las solicitudes sean para un pequeño subconjunto? En el último caso, un caché podría ser útil; en el primero, no tanto. Tenga en cuenta que el caché en el controlador de disco es útil principalmente para almacenar en caché escrituras (si el caché no es volátil), lo cual es útil para aplicaciones intensivas en fsync(), como bases de datos. Para el servicio de imágenes, sospecho que el beneficio no será tan grande.
Un problema con los FS en clúster y distribuidos es que son más complicados de configurar y, especialmente, los FS distribuidos son menos maduros que los FS "normales" de un solo nodo. Un FS de clúster generalmente significa almacenamiento compartido, lo que significa una SAN relativamente costosa si desea evitar puntos únicos de falla.
Una alternativa sería configurar un clúster que ejecute algún tipo de similar a Amazon S3 que proporcione un almacenamiento de valores clave replicado y distribuido accesible mediante HTTP. P.ejalmacenamiento de pila abierta.
Respuesta3
Mucho depende de la frecuencia con la que se utilizarán esos elementos. Si puede esperar que un pequeño porcentaje de ellos esté muy activo a la vez, entonces es posible que desee considerar Varnish para realizar el manejo del front-end y equilibrar la carga con los backends nginx/lighttpd. Dado que las imágenes utilizadas con frecuencia se almacenarían en caché, la velocidad del disco es un poco menos importante.
Sin embargo, si las imágenes no se solicitan repetidamente y el almacenamiento en caché no proporcionaría un gran impulso, nginx/lighttpd en uno o dos servidores sería suficiente. También debes considerar la cantidad de ancho de banda que vas a entregar. El sistema operativo almacenaría fácilmente en caché 800 MB/s de un pequeño subconjunto de su conjunto de datos. 800 MB/s de un gran subconjunto de su conjunto de datos probablemente se encontrarán con un cuello de botella de IO, ya que no puede sacar los datos del disco lo suficientemente rápido como para servirlos, en cuyo caso necesitará dividir su sistema en suficientes partes para tener el IO. banda ancha.
Aunque esté ejecutando raid-6, eso no sustituye a las copias de seguridad, por lo tanto, presupuesta una máquina similar para realizar copias de seguridad, o posiblemente para actuar como un servidor de almacenamiento de conmutación por error.
Respuesta4
Elegiría un clúster personalizado en lugar de un FS distribuido, porque es más sencillo de entender y solucionar problemas, sin dejar de funcionar. Es decir, las ventajas y desventajas de confiabilidad de su propio clúster son obvias, mientras que es una tarea en sí misma descubrir cómo reacciona un FS distribuido ante un servidor inactivo o un conmutador fallido.
Una posible solución a su tipo de problema es dividir todo el archivo fotográfico en partes (digamos, 2 partes) y hacer que la identificación de la parte sea explícita en la URL (por ejemplo, convertirlo en un subdominio o un parámetro GET que sea fácil de extraer con herramientas regulares). expresiones). Luego, tendrás 4 servidores de almacenamiento con fotos (2 servidores para cada parte). Utilice el quinto servidor como proxy inverso que distribuye y equilibra la carga. Los cinco servidores pueden ejecutar lighttpd. Es decir, propongo una solución muy tonta, pero funcional (para la empresa en la que trabajé, con una carga total de ~5000 solicitudes por segundo, archivos con un tamaño de 3 a 10 KB, 8 TB de archivos únicos en total, un servidor de 24 backends que , sin embargo, ejecute un demonio HTTP personalizado en lugar de la solución lighttpd).
En cuanto a los discos y la RAM: utilizamos un software RAID-0 compuesto por cuatro discos SATA rápidos pero económicos en cada servidor (si falla un disco, todos los datos se pueden copiar de todos modos desde una réplica en un servidor diferente), además de una solución personalizada. para desconectar todo el servidor después de un único error de lectura. RAID-5 y RAID-6 son muy malos en cuanto a velocidad, incluso si falla un disco, no los use. En los servidores de contenidos es imprescindible mucha RAM (como caché de disco), busca 24 GB o más. Incluso entonces, prepárate para un calentamiento de 30 minutos. En el proxy inverso, si usa lighttpd, tenga en cuenta que almacena toda la respuesta ascendente en la RAM lo más rápido posible y puede pasar mucho tiempo enviando la foto almacenada en caché a alguien mediante acceso telefónico o GPRS (y durante ese tiempo). , necesita ese buffer en RAM). También tomamos 24 GB solo para tener configuraciones idénticas, pero no estoy seguro de si esto es excesivo. La caché HTTP basada en memoria en el proxy inverso no es esencial (¡incluso si hay imágenes calientes!), porque la caché de disco proporcionada por el sistema operativo en los backends funciona igual de bien.
Para asegurarse de que todos los servidores que sirven la misma parte de su archivo tengan los mismos datos: esto es fácil. Al publicar fotos, simplemente cópielas en todos los servidores. Luego use rsync en partes antiguas del archivo para corregir cualquier discrepancia, haciendo así una copia del maestro.