Concours interne d ingénieur des systèmes d information et de communication. «Session 2010» Meilleure copie "étude de cas architecture et systèmes"

Transcription

1 Concours interne d ingénieur des systèmes d information et de communication «Session 2010» Meilleure copie "étude de cas architecture et systèmes" Note obtenue : 14,75/20 HEBERGE-TOUT Le 25 mars 2010 A l attention de Monsieur le directeur des systèmes d information Objet : Etude sur les trois gammes de produits. Documents : la documentation fournie en livret. Au vu de l existant, concernant la sécurisation des sites physiques via gardiennage, vidéosurveillance et alarme, le mécanisme de rendez-vous et de listing mis à jour de manière régulière pour accéder aux installations, le niveau de sécurité des locaux me semble correct. Il n est cependant pas détaillé la localisation des serveurs. Il me semble opportun de rappeler que pour palier une catastrophe tel que le feu, l inondation ou la coupure d énergie, il est important de mettre deux entités de serveurs sur deux sites distincts et distants. Chaque salle de production devra recevoir deux points d énergie provenant de deux circuits différents. Ces deux zones serveurs devront être reliées par des liaisons privées et sécurisées de données. Les sites doivent être gérés à distance afin de centraliser les alarmes fournies par les systèmes. Un système de nuage virtualisé (cloud computing) est recommandé pour nos offres. Il nous permettra des maîtrises d énergies, ainsi qu une répartition de charge sur nos divers serveurs. Cas de l offre «fiabilité avant tout» Ce produit doit être mis en œuvre sur le principe de la haute disponibilité. Le client se connecte sur un accès central qui fournira une liaison au site dit opérationnel. Les entités doivent être la réplique de l autre en temps réel et posséder un système de «ligne de vie». Ce mécanisme déterminera la disponibilité ou non du site. Dans le cas d incident majeur, le second site s activera seul, en fonction des procédures qui devront être testées.

2 Chaque serveur «tiers» fera partie d une ferme de serveurs et l hyperviseur qui contrôle chaque ferme enverra son état d alarme sur le site central. Les deux sites pourront travailler avec un système RAID du type miroir. Exemple d architecture : - Les fermes de serveurs : hyperviseur VSphare - Système RAID : Raid logiciel via réseau sous crnix - LVS : heartbeat avec une répartition de charge de gestion de ligne de vie des différents services. Remontée d alarme de fonctionnement sur le monitoring central - NAS : stockage des bases de données avec l accès local comme prérequis fourni par les experts de base de données et les administrateurs systèmes. Les clients accèderont à leurs données via des méthodes d accès sécurisées avec échanges de certificats. Les connexions pourront s effectuer par l intermédiaire de navigateurs web. 2

3 En conclusion, en cas de défaillance, le système peut basculer d un site vers un autre en un temps très court. Ce délai est induit par la détection de panne et le démarrage des services distants. Les données étant répliquées en continue, celles-ci sont immédiatement disponibles. Au même instant, les alarmes de dysfonctionnement remontent au centre de supervision qui gèrera les marches à suivre pour le dépannage. Cas de la «performance avant tout» Ce produit doit être mis en œuvre sur un système de ferme de serveurs. L objectif est de donner au client des temps de réponses les plus faibles possibles. La virtualisation nous permettra de prendre «possession» de moyens physiques répartis via un système de cluster. Lorsque les requêtes l imposent, la charge processeur pourra être répartie sur plusieurs machines. Un système de cache doit être mis en place afin de répondre au plus vite aux requêtes fréquemment posées. Hyperviseur de la ferme : Vsphere Serveur de cache : squid Lorsqu un client lance un travail, il se connecte au système de cache qui pourra lui répondre très rapidement sans charger le système tiers applicatif. Dans le cas où le travail demande un fonctionnement des services, ceux-ci sont sollicités en fonction de leur disponibilité (répartition de charge). Suivant le taux d occupation de charge de la mémoire ou du processeur, celui-ci est à définir avec le client et nos techniciens, les machines virtuelles pourront s étendre dans un intervalle défini. Exemple : une machine virtuelle peu sollicitée aura le droit d occuper au minimum 1% de la mémoire physique du serveur sur lequel elle est hébergée. Inversement, elle aura le droit d utiliser 3

4 en cas d utilisation intensive 60% du cluster mémoire de la ferme. Il en va de même pour le processeur. La réplication de l architecture pourra se faire sur le second site en fonction des disponibilités distantes. Mais elle ne nécessite pas de temps réel. La sécurité d accès s effectuera comme dans le choix précédent. En conclusion, les serveurs virtuels devront en fonction de la sollicitation utiliser tout ou partie des ressources qui seront allouées. Le système de cache couplé à la répartition de charge permettra de répondre aux attentes de performance du client. Cas de «l efficacité à moindre coût» Les fermes de serveurs tels que je vous propose l utilisation dans les deux cas précédents, nous permet d offrir une part non négligeable à cette gamme de produits. En effet, nos fermes ne seront que rarement sollicitées à 100%. Il existe donc une part pour mettre en œuvre des machines virtuelles. Au vu du reliquat, nous pouvons alors disposer d une offre qui n impose ni haute disponibilité, ni performance. Cette architecture revêtira le modèle type. La sécurité correspond aux mêmes recommandations que définies dans les deux autres offres. La puissance des machines physiques est suffisante pour cette offre qui ne pourra pas être considérée comme un «sous-produit». La réplication vers l autre site devra s effectuer régulièrement. La méthode de supervision des alarmes étant centralisée, cette gamme répondra aux mêmes exigences de la version «performance» et «fiabilité». 4

5 En conclusion Le niveau de sécurité tant d accès aux locaux que de maintien opérationnel des données que nous gérons est élevé. La disponibilité, la fiabilité sont assurées grâce à un système de deux sites supervisés par un troisième. La traçabilité des informations est effectuée via une remontée constante des journaux de serveurs. La mise en application de la technologie de virtualisation nous permet de maîtriser au mieux la quantité de matériel et l énergie utilisée. La réutilisation des technologies sur nos trois offres nous permet d optimiser les compétences et de maîtriser les coûts de fonctionnement. Au vu du choix que je propose de manière primordiale, le maintien d une veille technologique sur les malwares qui s appuient sur les architectures virtualisées, qu elles soient matérielles ou logicielles. C est le point faible de cette étude. Le recul face à ce type de menace n est malheureusement que très épars. 5