Contexte
L'un de mes clients est un cabinet d'avocats axé sur les flux de travail et dépendant des TI, qui compte environ 50 sièges. Ils ont été audités par l'un de leurs clients (un prêteur hypothécaire réglementé par la FSA) et ont déclaré que leur site unique constituait une menace pour la continuité des activités. J'ai proposé de diviser leur entreprise en deux bits:
Côté client - PC, moniteurs, chaises, bureaux, commutateurs LAN et routeur et pare-feu
Côté serveur - Les machines virtuelles exécutant Active Directory, Exchange, SQL, SharePoint et d'autres applications métier, des machines de travail «robot» et des services Bureau à distance (environ 14 machines virtuelles au total)
L'idée est que nous pouvons stocker de l'équipement et mettre en place des dispositions pour reproduire rapidement au moins un environnement côté client de capacité réduite à un autre emplacement, ou même demander aux utilisateurs de se connecter depuis leur domicile si nécessaire.
Le côté serveur représente un plus grand défi, car il comprend des services publiés à partir de leur connexion IP (actuellement ADSL, qui sera bientôt 100 Mbps fibre) et environ 3 To de données, sans compter les sauvegardes. J'ai proposé de déplacer l'ensemble de l'environnement côté serveur de leurs salles de serveurs sur site auto-hébergées actuelles vers une installation hébergée. Je veux toujours le même niveau de confidentialité - cela doit être protégé par un pare-feu depuis Internet, sauf pour le petit nombre de services publiés, et ils seraient mieux servis à partir d'une machine virtuelle de serveur Web dans une DMZ.
Il existe actuellement deux salles de serveurs, chacune contenant un nœud d'un SAN répliqué et un hôte de cluster Hyper-V. Couplé à des liaisons redondantes Fibre Channel et Ethernet, cela signifie que le système continuera de fonctionner même si une salle de serveurs entière est perdue. Je souhaite que l'environnement côté serveur hébergé soit tout aussi résistant à la perte d'un centre de données unique.
Fondamentalement, je veux la sécurité, la disponibilité et le contrôle que j'obtiens de l'auto-hébergement local, mais dans le cloud, avec une diversité géopraphique d'au moins 30 km. Je ne veux pas non plus vraiment acheter un kit et le monter moi-même et me soucier de la durée de vie et du remplacement du matériel, des sauvegardes, etc.
Des questions
Le SAN de réplication et le cluster Hyper-V doivent-ils être répliqués dans le centre de données, ou les grands hébergeurs et fournisseurs de cloud ont-ils d'autres moyens d'assurer la disponibilité?
Il semble qu'Amazon AWS possède tous les bits nécessaires (EC2, EBS, S3, VPC, VPN, etc.), mais un seul centre de données européen. À quel type de disponibilité puis-je m'attendre? Par exemple, s'ils ont une panne majeure dans leur centre de données en Irlande (imaginez un avion qui y atterrit, par exemple), qu'adviendra-t-il des services qui y sont hébergés? Et qu'en est-il des problèmes généraux de fiabilité?
Cela peut-il être fait en utilisant Windows Azure, Rackspace Cloud ou tout autre service cloud?
Merci d'avoir pensé à ma question.
Réponses:
Je suggère de conserver vos opérations principales à l'intérieur et de dupliquer vos serveurs et vos données à l'extérieur en tant que sauvegarde.
EC2 est assez génial pour cela. Créez des images de machine de chacun des serveurs dont vous avez besoin et séparez vos données d'eux. Chaque fois que vous corrigez un logiciel sur une machine interne, planifiez de créer le correctif correspondant sur votre boîtier EC2. Cela réduira vos coûts pour la ressource de sauvegarde, car vous n'aurez pas besoin que la machine fonctionne la plupart du temps, vous paierez donc simplement le stockage, pas le coût de la machine.
Transférez également vos données sur le réseau. Votre déménagement initial vous prendra plus de 3 jours, mais les incréments devraient être beaucoup plus fluides.
En conservant EC2 comme sauvegarde, vous éviterez / minimiserez les coûts matériels, éviterez de dépendre d'un site distant et d'une connexion Internet pour les activités quotidiennes et vous offrirez la possibilité de lancer rapidement des services en cas de panne.
Questions et réponses directes
Ils ont leurs méthodes pour assurer la fiabilité. Vous pouvez payer pour le service avec un SLA à disponibilité plus élevée. Ayez toujours des sauvegardes de toute façon.
Si ça va boum, ça va boum. Si vous ne comptez que sur eux, répliquez-les dans d'autres centres de données. Personnellement, avec ma suggestion de les utiliser uniquement comme sauvegarde, je ne m'en inquiéterais pas trop. Si l'UE se développe suffisamment pour que votre entreprise et l'UE EC2 se déconnectent, alors la vie se produit. Pour une entreprise de 50 personnes, je ne prendrais pas en compte ce type de risque sur plus de 2 sites distants (votre bureau et un centre de données EC2).
Probablement, mais je ne me suis familiarisé qu'avec les services Amazon.
la source
Aller sur le cloud, ce n'est pas simplement prendre tous les serveurs et déplacer ces instances ailleurs. Votre infrastructure doit être conçue pour fonctionner dans le cloud. Sinon, vous ne verrez pas la résilience loin des niveaux que vous aviez dans votre propre salle de serveurs. Ce sont des environnements complètement différents.
Lisez à propos de Chaos Monkey de Netflix et également de Coding Horror .
la source
En ayant un site DR avec une réplique de votre infrastructure et un RPO / RTO acceptable dans certains cas, le site DR a accordé son niveau opérationnel et la vue d'ensemble des services peut être mieux adaptée au PROD et tirer parti de son infrastructure datacenter + entièrement pour les deux prod / dr scénarios.
La mise à l'échelle du site Active Directory, peut faire
Clients légers, modèle hébergé avec serveur Citrix est une meilleure pratique recommandée.
Connexion MPLS au fournisseur et zones multiples + dmz ainsi que les exigences de confidentialité, de sécurité et d'audits. valider l'offre pour offrir un port sûr, saas70 (maintenant ssae16), pci.
peut faire, selon les facteurs, l'architecture de la base de données, l'édition sous licence (standard / entreprise) rpo / rto requise et plus d'informations sur le flux de données.
pour la sécurité, le contrôle avancé des modifications, la gestion des journaux, la détection des intrusions ... les temps de réponse typiques entre les centres de données à moins de 6 heures doivent être <70 ms
Des questions
ne recommandant pas la réplication au niveau du bloc sur les installations, cela peut devenir coûteux, il existe de nombreuses autres options sur la pile logicielle application / db pour gérer cela.
Si vous êtes sur un hôte et que cela est en panne, vos applications sont en panne. il y a d'autres sociétés qui peuvent offrir cela aussi, certaines fonctionnent bien avec amazon, voir Datapipe.
La stratosphère est une approche intéressante que vous voudrez peut-être étudier, envoyez-moi un ping si vous souhaitez discuter
la source
Je suis désolé que ce soit un peu tard pour la fête, mais Jeff Ferland a raison au sujet du boom.
Votre question sur un avion atterrissant sur le centre de données d'Irlande pourrait tout aussi bien se traduire par ce qui se passe si un avion atterrit sur le bureau ou la salle des serveurs de vos clients. Les deux sont des situations catastrophiques qui échappent au contrôle de quiconque et entraîneront une perte de données pour votre client.
Si vous vous inquiétez de ce genre de chose qui arrive à votre client, vous devriez déjà prendre des mesures pour mettre hors site les serveurs sur site de vos clients.
Si vous êtes soucieux de protéger votre entreprise, votre accord client doit contenir une clause vous protégeant de toute responsabilité pour des événements hors de votre contrôle, et peut-être pour quelque chose qui est sous votre contrôle.
la source