Ha pasado un tiempo, pero pensé que nuestro caso de uso sería útil ...
Primer + punto en AWS .
Tenemos un servidor dedicado en un host bien conocido. Es una gran especificación, y ha estado tratando de ejecutar tiendas Magento durante años. Hemos ajustado y jugado con la configuración de una manera que no derribará los sitios. Nuestro host no había instalado APC (antes de comenzar), por lo que lo instalaron a pesar de que les pagamos para construir un servidor Magento, redujo nuestros sitios durante 3 horas con una versión de PHP defectuosa. Logramos ponerlo en marcha nuevamente con un APC deshabilitado.
en AWS Tenemos una réplica exacta de todos nuestros AMI (NGINX, NGINX + Varnish, Servidor de control) esperando en AWS que podamos encender y jugar en cualquier momento. Podemos clonar el volumen de EBS en el que se almacenan nuestros datos de Vhosts para asignar algunas direcciones IP a nuestras direcciones IP internas de VPC, engancharlas al servidor y estar en funcionamiento de inmediato. Haga nuestra PRUEBA para asegurarse de que todo esté bien y realice cambios en el sistema LIVE y apague la réplica hasta que sea necesario nuevamente. En este punto, los cambios que hicimos en la configuración, clonamos en una nueva versión de AMI.
Segundo + punto para AWS . Alcanzamos un límite de dirección IP en nuestro host actual. En AWS Tenemos cualquier número de direcciones IP internas de VPC y hemos asignado a nuestra cuenta 20 direcciones IP externas elásticas que podemos asignar a direcciones IP internas. Las funciones de red en AWS VPC son absolutamente sorprendentes. Es irreal cómo han empaquetado esto para los administradores de red de bajo nivel. Tomó 3 días obtener algunas nuevas direcciones IP en nuestro host y agregarlas a su firewall.
Aquí es donde le doy a AWS otro +
Las copias de seguridad en nuestro servidor dedicado actual son solo un clon de una carpeta contenida en una bóveda de copias de seguridad. Básicamente una unidad montada. Una unidad montada solo disponible para ese servidor. Entonces, en el caso de una interrupción masiva, tendríamos que obtener una nueva configuración del servidor, montar el almacén de copias de seguridad, instalar y configurar nuestro nuevo servidor exactamente de la misma manera (gran tarea), luego recrear los datos. Nuestro anfitrión cuenta con 4 horas de entrega de nuevo hardware, pero eso no significa nada para mí. Está obteniendo la configuración y los sitios configurados nuevamente.
Nuestro negocio ofrece soluciones a empresas para todo el ciclo de vida web. Consultoría, diseño, SEO, soporte y mantenimiento. Si tuviéramos un corte en nuestro dedicado, cerraríamos el negocio, porque pasarían días antes de que nos pusiéramos de pie nuevamente. No podemos tener este escenario ni siquiera en nuestro mapa "qué pasaría si". Simplemente no puede suceder.
En AWS actualmente tenemos nuestro contenido web en instancias de AWS montadas en volúmenes EBS a 750IOPS y una segunda instancia (lo que llamamos un servidor de control) que vuelve a sincronizar los datos en otra zona de disponibilidad a tiempo y actualiza una instancia para la última configuración en caso de que necesita iniciar una instancia desde ese AMI. Para ello, sincroniza todas las configuraciones de NGINX, archivos de configuración de PHP-FPM.
Entonces ahora tenemos dos conjuntos de datos; un AMI que es un clon del servidor web NGINX de producción, y una copia del contenido del directorio Vhosts con archivos de configuración y Vhosts en caso de que necesitáramos iniciar un nuevo servidor.
Aquí es donde AWS obtiene otro +
Nuestro servidor dedicado tiene problemas en las horas punta. Sí, ejecutamos Magento, por lo que es un poco diferente de algunas aplicaciones. Tenemos una configuración de disco RAID Quad Core de 32 GB y, a veces, tiene problemas, incluso tiene interrupciones cuando un cliente envía una o dos campañas de correo electrónico al mismo tiempo. Apenas podemos hacer nada. Tiene MySQL en él localmente, su memoria está optimizada para MYSQL pero los discos son pobres.
En AWS ejecutamos 3 instancias de CPU alta. 2 servidores web NGINX / PHP-FPM, más una instancia de caché de barniz NGINX SSL +. Luego tenemos un servidor Magento Admin más pequeño que aloja todas las imágenes y medios que luego se asignan a través de CNAMES a través de Cloudfront. Estas son todas las instancias reservadas para mantener bajos los costos.
Luego tenemos nuestras bases de datos en RDS en una instancia grande de 2000IOPS a la que se conectan ambos servidores web que toman instantáneas cada noche. Con un poco de tiempo de inactividad (tenemos páginas de mantenimiento para nuestras tiendas) podemos cambiar el tamaño de las IOPS y el tamaño de la instancia. Lo mejor de RDS es que podemos tomar una instantánea más reciente y crear una nueva base de datos para pruebas y desarrollo. Entonces apaga. Es simplemente fantástico.
Utilizamos Elastic Cache + y ahora estamos probando Redis para la gestión de caché para los servidores web front-end. Nuevamente podemos cambiar el tamaño hacia arriba y hacia abajo.
Podemos agregar nuevas instancias de servidores de alta CPU bajo demanda (clonando nuestra interfaz NGINX) en la mezcla con un poco de trabajo manual para ayudar en Navidad y si es necesario cuando un cliente nos dice que enviará una campaña de 100,000 correos electrónicos de venta de Productos con 75% de descuento.
Ahora estamos PROBANDO nuestra escala automática en Amazon y cómo hacemos que los servidores se activen, agreguemos direcciones IP, actualicemos las configuraciones de NGINX, etc. y comencemos a trabajar sin problemas, pero luego también saquemos el servidor y lo apaguemos durante los momentos de silencio (cerca del tiempo).
AWS + +
Mover datos en nuestro dedicado es interrumpir el servicio. La copia, Rsync MV, etc. afectará a los discos IO, lo que a su vez ralentiza los sitios.
Usar volúmenes e instantáneas en AWS es muy fácil. Realmente no necesito decir nada aquí.
AWS +++++++
Administración y control general del servidor. En realidad, no hay realmente visibilidad en nuestro servidor dedicado. Es solo SSH y algunos informes de servidores realmente malos que nuestro Host envía mensualmente.
En AWS podemos ver estadísticas que, aunque no son del todo precisas en mi opinión sobre el rendimiento de las aplicaciones, sí le dan una buena idea de cómo está funcionando la instancia real. Tenemos configuraciones de alarmas para detectar problemas.
Conclusión
* AWS vs Dedicado - Pure Power. * Para todos los trolls de AWS, no digo ni intentaré decir que AWS realizará un dedicado con dos Quads, cargas de memoria SSD, etc. Incluso AWS no intentará decírtelo. Hay cosas que puede hacer para mejorar el rendimiento, EBS Optimized, el aprovisionamiento de IOPS y cambiar el tamaño de las instancias, pero sé que un hueso puro dedicado tendrá un rendimiento superior.
AWS vs Dedicated - Arquitectura para una solución adecuada
Los servidores dedicados se sentaron en un estante solitario en algún lugar que simplemente no me servirán. En mi opinión, esta no es una situación del mundo real ni adecuada como solución cuando proporciono a las empresas una solución para administrar sus tiendas o sitios.
Tenemos toda nuestra red de servidores en AWS VPC, podemos expandirnos, contratarnos, ver dónde están todos nuestros recursos en un solo lugar. Como solución, nunca querría volver a un servidor dedicado.
Si estaba ejecutando un sitio que podría lidiar con una interrupción masiva y podríamos esperar para reconstruir un nuevo servidor con el host, o si estaba dispuesto a usar dos hosts o AWS como respaldo y mover un sitio si un dedicado se caía, entonces este es el La única forma en que haría esto. Esto en sí mismo es un problema que consume mucho tiempo.
Costos
La razón por la cual los servidores dedicados ahora son tan baratos es porque AWS ofrece formas económicas de administrar su propio mini centro de datos, que es para lo que muchos centros de datos solían agregar premium. Hay un cambio en los precios y los centros de datos ahora tienen que usar técnicas de eliminación de escoria contra AWS para vender sus servicios o gritar sobre la potencia del servidor sin procesar y la falta de algunos tipos de instancias de AWS.
Las personas que comparan un servidor dedicado con una instancia de AWS realmente deberían tener en cuenta todos los servicios adicionales que AWS ofrece en torno a esa instancia de servidor y asignarlo a un precio dedicado. Déjame expandirme. Al salir y dar aviso sobre el contrato a nuestro anfitrión actual, dijeron AWS esto, mal desempeño, costos de EBS, etc., así que enviamos un mapa de solución de lo que queríamos.
- LAN privada con políticas de seguridad / enrutamiento y firewalls
- 20 direcciones IP externas, con la capacidad de reasignar a través de servidores sobre la marcha o mediante el panel de control
- 4 servidores con 8 núcleos cada uno con 16 hilos
- 32 GB de RAM
- Servidor de base de datos con la capacidad de proporcionar hasta 10000 IOPS, pero generalmente alrededor de 2000IOP
- Copias de seguridad de apuntar y hacer clic
- Sin contrato o solo 12 meses
No solo no pudieron hacer todo esto, dijeron que si pudieran proporcionar la pila de software para hacerlo, nuestros costos de configuración habrían sido de alrededor de £ 10,000 más tarifas mensuales.
Los servidores dedicados superarán a las nubes, pero esto ya es cosa del pasado. Puedes verlo en el marketing contra la computación en la nube. La computación en la nube es la solución completa que une a las pequeñas empresas para tener su propio centro de datos. En mis ojos y después de configurar muchas soluciones de AWS, AWS es la solución comercial en este momento
Sé que cuando compro una instancia de AWS no es solo la instancia, sino todo el kit adjunto. Sé que cuando compro un servidor dedicado, realmente es solo un servidor arrojado en un bastidor con un cable conectado.
Sé £ por £ que un servidor dedicado será mejor que AWS, pero para mis clientes y necesidades empresariales REALES, AWS supera en gran medida las soluciones dedicadas