Mover todos los servidores internos a la nube


11

Antecedentes

Uno de mis clientes es un bufete de abogados que depende del flujo de trabajo y depende de TI con aproximadamente 50 puestos. Han sido auditados por uno de sus clientes (un prestamista hipotecario regulado por la FSA) y se les ha dicho que su sitio único es una amenaza para la continuidad del negocio. He propuesto que particionemos su negocio en dos bits:

  1. Lado del cliente: PC, monitores, sillas, escritorios, conmutadores LAN y enrutador y firewall

  2. Del lado del servidor: las máquinas virtuales que ejecutan Active Directory, Exchange, SQL, SharePoint y otras aplicaciones de línea de negocio, máquinas de trabajo "robot" y servicios de escritorio remoto (alrededor de 14 máquinas virtuales en total)

La idea es que podamos almacenar equipos y establecer arreglos para reproducir rápidamente al menos un entorno del lado del cliente de capacidad reducida en una ubicación alternativa, o incluso hacer que los usuarios se conecten desde sus hogares si es necesario.

El lado del servidor representa un desafío mayor, ya que incluye servicios publicados desde su conexión IP (actualmente ADSL, que pronto será fibra de 100 Mbps) y aproximadamente 3 TB de datos, sin incluir copias de seguridad. He propuesto que traslademos todo el entorno del lado del servidor de sus salas de servidores locales autohospedadas actuales a una instalación alojada. Todavía quiero el mismo nivel de privacidad: esto tiene que eliminarse de Internet a excepción de la pequeña cantidad de servicios publicados, y sería mejor atenderlos desde una máquina virtual de servidor web en una DMZ.

Actualmente hay dos salas de servidores, cada una con un nodo de una SAN replicada y un host de clúster Hyper-V. Junto con enlaces redundantes de canal de fibra y Ethernet, esto significa que el sistema seguirá funcionando incluso si se pierde toda una sala de servidores. Quiero que el entorno del lado del servidor alojado sea igualmente resistente a la pérdida de un solo centro de datos.

Básicamente, quiero la seguridad, disponibilidad y control que obtengo del autohospedaje local, pero en la nube, con una diversidad geopráfica de al menos 30 km. Tampoco quiero comprar un kit, acumularlo yo mismo y preocuparme por la vida útil y el reemplazo del hardware, las copias de seguridad, etc.

Preguntas

  1. ¿La replicación de SAN y el clúster de Hyper-V es algo que debería intentar replicar en el centro de datos, o los grandes proveedores de alojamiento y los proveedores de la nube tienen otras formas de garantizar la disponibilidad?

  2. Parece que Amazon AWS tiene todos los bits necesarios (EC2, EBS, S3, VPC, VPN, etc.), pero solo un centro de datos de la UE. ¿Qué tipo de disponibilidad puedo esperar? Por ejemplo, si tienen una interrupción importante en su centro de datos de Irlanda (imagine un avión que aterriza en él, por ejemplo), ¿qué pasará con los servicios alojados allí? ¿Y qué hay de los problemas generales de confiabilidad?

  3. ¿Se puede hacer esto usando Windows Azure, Rackspace Cloud o cualquier otro servicio en la nube?

Gracias por considerar mi pregunta.


77
¡Puede que hayas ganado el bingo de palabra de moda!
MDMarra

Respuestas:


3

Sugiero mantener sus operaciones principales adentro y duplicar sus servidores y datos afuera como respaldo.

EC2 es bastante impresionante para esto. Cree imágenes de máquina de cada uno de los servidores que necesita y mantenga sus datos separados de ellos. Siempre que parchee el software en una máquina interna, programe para hacer el parche correspondiente en su caja EC2. Esto mantendrá sus costos bajos para el recurso de respaldo porque no necesitará que la máquina funcione la mayor parte del tiempo, por lo que solo pagará el almacenamiento, no el costo de la máquina.

Envíe sus datos a través de la red también. Su movimiento inicial le llevará más de 3 días, pero los incrementales deberían ser mucho más suaves.

Al mantener EC2 como su copia de seguridad, evitará / minimizará los costos de hardware, evitará depender de un sitio remoto y una conexión a Internet para los negocios cotidianos, y se proporcionará la capacidad de activar rápidamente los servicios en un corte de energía.

Preguntas y respuestas directas

¿La replicación de SAN y el clúster de Hyper-V es algo que debería intentar replicar en el centro de datos, o los grandes proveedores de alojamiento y los proveedores de la nube tienen otras formas de garantizar la disponibilidad?

Tienen sus métodos para garantizar la fiabilidad. Puede pagar el servicio con un SLA de mayor disponibilidad. Siempre tenga copias de seguridad de todos modos.

Parece que Amazon AWS tiene todos los bits necesarios (EC2, EBS, S3, VPC, VPN, etc.), pero solo un centro de datos de la UE. ¿Qué tipo de disponibilidad puedo esperar? Por ejemplo, si tienen una interrupción importante en su centro de datos de Irlanda (imagine un avión que aterriza en él, por ejemplo), ¿qué pasará con los servicios alojados allí? ¿Y qué hay de los problemas generales de confiabilidad?

Si se dispara, se dispara. Si solo confía en ellos, repítalos en otros centros de datos. Personalmente, con mi sugerencia de usarlos solo como respaldo, no me preocuparía demasiado. Si la UE se dispara lo suficiente como para que su empresa y EC2 EU se desconecten, entonces la vida pasa. Para una empresa de 50 personas, no consideraría ese tipo de riesgo en más de 2 sitios distantes (su oficina y un centro de datos EC2).

¿Se puede hacer esto usando Windows Azure, Rackspace Cloud o cualquier otro servicio en la nube?

Probablemente, pero solo me he familiarizado con los servicios de Amazon.


2

Ir a la nube no es solo tomar todos los servidores y mover esas instancias a otro lugar. Su infraestructura debe ser construida para trabajar en la nube. De lo contrario, no verá la resistencia en ningún lugar cerca de los niveles que tenía en su propia sala de servidores. Esos son ambientes completamente diferentes.

Lea sobre Chaos Monkey de Netflix y también de Coding Horror .


No se trata de proporcionar un servicio de Internet 24/7. Las lecciones de Netflix no serán muy aplicables.
Jeff Ferland el

@JeffFerland: "incluye servicios publicados desde su conexión IP", también sus propios usuarios no aprecian cuando la red está inactiva, alejándola, especialmente si tiene esa arquitectura interna, no reducirá la cantidad de fallas modos ...
Hubert Kario

En cierto modo, esto responde a mi pregunta. No tengo la oportunidad de rediseñar nada, tiene que ser como es, y eso significa que necesito instancias individuales para ser confiables porque son puntos únicos de falla. Entonces, creo que AWS es un mal lugar para estar en este proyecto, y lo que se necesita es alojamiento personalizado. Los enlaces fueron realmente informativos, gracias.
Alasdair CS

1

Uno de mis clientes es un bufete de abogados que depende del flujo de trabajo y depende de TI con aproximadamente 50 puestos. Han sido auditados por uno de sus clientes (un prestamista hipotecario regulado por la FSA) y se les ha dicho que su sitio único es una amenaza para la continuidad del negocio. He propuesto que particionemos su negocio en dos bits:

Al tener un sitio de DR con una réplica de su infraestructura y un RPO / RTO aceptable, en algunos casos el sitio de DR otorgó su nivel operativo y la descripción general del servicio puede ser más adecuada para el PROD y aprovechar su centro de datos + infraestructura por completo para ambos productos / Dr escenarios.

  1. Lado del cliente: PC, monitores, sillas, escritorios, conmutadores LAN y enrutador y firewall

  2. Del lado del servidor: las máquinas virtuales que ejecutan Active Directory, Exchange, SQL, SharePoint y otras aplicaciones de línea de negocio, máquinas de trabajo "robot" y servicios de escritorio remoto (alrededor de 14 máquinas virtuales en total)

Escalar el sitio del directorio activo, puede hacer

La idea es que podamos almacenar equipos y establecer arreglos para reproducir rápidamente al menos un entorno del lado del cliente de capacidad reducida en una ubicación alternativa, o incluso hacer que los usuarios se conecten desde sus hogares si es necesario.

Clientes delgados, el modelo alojado con el servidor Citrix es una práctica recomendada.

El lado del servidor representa un desafío mayor, ya que incluye servicios publicados desde su conexión IP (actualmente ADSL, que pronto será fibra de 100 Mbps) y aproximadamente 3 TB de datos, sin incluir copias de seguridad. He propuesto que traslademos todo el entorno del lado del servidor de sus salas de servidores locales autohospedadas actuales a una instalación alojada. Todavía quiero el mismo nivel de privacidad: esto tiene que eliminarse de Internet a excepción de la pequeña cantidad de servicios publicados, y sería mejor atenderlos desde una máquina virtual de servidor web en una DMZ.

Conexión MPLS al proveedor y múltiples zonas + dmz, así como requisitos satisfactorios de privacidad, seguridad y auditorías. validando la oferta para ofrecer puerto seguro, saas70 (ahora ssae16), pci.

Actualmente hay dos salas de servidores, cada una con un nodo de una SAN replicada y un host de clúster Hyper-V. Junto con enlaces redundantes de canal de fibra y Ethernet, esto significa que el sistema seguirá funcionando incluso si se pierde toda una sala de servidores. Quiero que el entorno del lado del servidor alojado sea igualmente resistente a la pérdida de un solo centro de datos.

puede hacer, dependiendo de los factores, la arquitectura de la base de datos, la edición con licencia (estándar / empresarial) requiere rpo / rto y más información sobre el flujo de datos.

Básicamente, quiero la seguridad, disponibilidad y control que obtengo del autohospedaje local, pero en la nube, con una diversidad geopráfica de al menos 30 km. Tampoco quiero comprar un kit, acumularlo yo mismo y preocuparme por la vida útil y el reemplazo del hardware, las copias de seguridad, etc.

para control avanzado de cambios de seguridad, gestión de registros, detección de intrusiones ... los tiempos de respuesta típicos entre los centros de datos dentro de las zonas horarias de 6 horas deben ser <70 ms

Preguntas

  1. ¿La replicación de SAN y el clúster de Hyper-V es algo que debería intentar replicar en el centro de datos, o los grandes proveedores de alojamiento y los proveedores de la nube tienen otras formas de garantizar la disponibilidad?

Sin recomendar la replicación a nivel de bloque sobre las instalaciones, esto puede ser costoso. Hay muchas otras opciones en la pila de software de aplicación / db para manejar esto.

  1. Parece que Amazon AWS tiene todos los bits necesarios (EC2, EBS, S3, VPC, VPN, etc.), pero solo un centro de datos de la UE. ¿Qué tipo de disponibilidad puedo esperar? Por ejemplo, si tienen una interrupción importante en su centro de datos de Irlanda (imagine un avión que aterriza en él, por ejemplo), ¿qué pasará con los servicios alojados allí? ¿Y qué hay de los problemas generales de confiabilidad?

Si está en un host y está inactivo, sus aplicaciones están inactivas. hay otras compañías que también pueden ofrecer esto, algunas funcionan bien con Amazon, vea Datapipe.

  1. ¿Se puede hacer esto usando Windows Azure, Rackspace Cloud o cualquier otro servicio en la nube?

La estratosfera es un enfoque interesante que quizás desee considerar, hágame un ping si desea discutir

Gracias por considerar mi pregunta.


1

Lo siento, es un poco tarde para la fiesta, pero Jeff Ferland tiene razón sobre el boom.

Su pregunta sobre el aterrizaje de un avión en el centro de datos de Irlanda también podría traducirse a lo que sucede si un avión aterriza en la oficina de su cliente o en la sala de servidores. Ambas son situaciones catastróficas que están fuera del control de cualquiera y resultarán en la pérdida de datos para su cliente.

Si le preocupa que ese tipo de cosas le sucedan a su cliente, ya debería estar tomando medidas para ubicar a los servidores fuera de las instalaciones de sus clientes.

Si le preocupa proteger su negocio, su acuerdo con el cliente debe tener una cláusula que lo proteja de ser responsable de eventos fuera de su control, y posiblemente de algo que esté bajo su control.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.