Sécurité et haute performances SQL SERVER
Fermé
ybenaabud
Messages postés
10
Date d'inscription
mercredi 23 octobre 2002
Statut
Membre
Dernière intervention
17 décembre 2011
-
21 sept. 2011 à 11:28
ybenaabud Messages postés 10 Date d'inscription mercredi 23 octobre 2002 Statut Membre Dernière intervention 17 décembre 2011 - 22 sept. 2011 à 19:59
ybenaabud Messages postés 10 Date d'inscription mercredi 23 octobre 2002 Statut Membre Dernière intervention 17 décembre 2011 - 22 sept. 2011 à 19:59
A voir également:
- Sécurité et haute performances SQL SERVER
- Tester les performances de son pc - Guide
- Mode securite - Guide
- Ps3 media server - Télécharger - Divers Réseau & Wi-Fi
- (+) Sql - Forum Programmation
- Filezilla server - Télécharger - Téléchargement & Transfert
12 réponses
Shu_Wong
Messages postés
36
Date d'inscription
samedi 20 août 2011
Statut
Membre
Dernière intervention
22 septembre 2011
5
Modifié par Shu_Wong le 21/09/2011 à 17:53
Modifié par Shu_Wong le 21/09/2011 à 17:53
Bonjour,
Tout d'abord félicitation pour le taf.
Ensuite pour l'archi le cluster de haute disponibilité est le plus approprié selon moi pour garantir la disponibilité du service (tout les noeuds en actif ca mange pas de pain) et vu que les produits MS semblent privilégiés du TSE pour les serveurs app.
Un max de RAM pour supporter toutes les sessions simultanées et vu les thunes qu'il faut mettre sur la table, quad ou exacore c'est pas ça qui va alourdir la douloureuse.
Pour garantir la continuité du service après sinistre, le mieux serait un backup de spare situé hors du bâtiment du cluster de prod et synchro irt avec reprise automatique d'activité en cas d'interruption d'activité du cluster de prod. Le délai de reprise d'activité dépasse rarement le centième de seconde, c'est transparent pour les utilisateurs et la restauration des données et des transactions en cours est aisée avec les logs qui sont synchro irt.
L'idéal pour une sécurisation maximale des données serait selon moi un SAN relié au cluster de prod en fiber channel avec des disques en raid combiné 15 (de tout les niveaux de raid que j'ai testé c'est le de mon point de vue le plus fiable) .
Un SAN en backup du SAN de prod (avec synchro irt des données du SAN de prod) et relié au cluster de spare serait idéal.
Sinon pas de raison que je prêche pas pour ma paroisse: Oracle c'est mainstream d'accord, mais c'est du bon, mangez-en.
Tout d'abord félicitation pour le taf.
Ensuite pour l'archi le cluster de haute disponibilité est le plus approprié selon moi pour garantir la disponibilité du service (tout les noeuds en actif ca mange pas de pain) et vu que les produits MS semblent privilégiés du TSE pour les serveurs app.
Un max de RAM pour supporter toutes les sessions simultanées et vu les thunes qu'il faut mettre sur la table, quad ou exacore c'est pas ça qui va alourdir la douloureuse.
Pour garantir la continuité du service après sinistre, le mieux serait un backup de spare situé hors du bâtiment du cluster de prod et synchro irt avec reprise automatique d'activité en cas d'interruption d'activité du cluster de prod. Le délai de reprise d'activité dépasse rarement le centième de seconde, c'est transparent pour les utilisateurs et la restauration des données et des transactions en cours est aisée avec les logs qui sont synchro irt.
L'idéal pour une sécurisation maximale des données serait selon moi un SAN relié au cluster de prod en fiber channel avec des disques en raid combiné 15 (de tout les niveaux de raid que j'ai testé c'est le de mon point de vue le plus fiable) .
Un SAN en backup du SAN de prod (avec synchro irt des données du SAN de prod) et relié au cluster de spare serait idéal.
Sinon pas de raison que je prêche pas pour ma paroisse: Oracle c'est mainstream d'accord, mais c'est du bon, mangez-en.
ybenaabud
Messages postés
10
Date d'inscription
mercredi 23 octobre 2002
Statut
Membre
Dernière intervention
17 décembre 2011
21 sept. 2011 à 18:10
21 sept. 2011 à 18:10
Merci beaucoup Shu_Wong pour tes précieuses réponses,
j'ai quand meme qlq questions (priere d'excuser mon ignorance :)
- Pourquoi tu dit que tous les noeuds en actif ça ne mange pas de pain ? est ce que les instances ne se partage pas le travail en eux en clustering ?
- d'après toi un seul serveur actif (avec un max de ram et cpu puissant suffit) ?
j'ai quand meme qlq questions (priere d'excuser mon ignorance :)
- Pourquoi tu dit que tous les noeuds en actif ça ne mange pas de pain ? est ce que les instances ne se partage pas le travail en eux en clustering ?
- d'après toi un seul serveur actif (avec un max de ram et cpu puissant suffit) ?
Shu_Wong
Messages postés
36
Date d'inscription
samedi 20 août 2011
Statut
Membre
Dernière intervention
22 septembre 2011
5
Modifié par Shu_Wong le 21/09/2011 à 18:33
Modifié par Shu_Wong le 21/09/2011 à 18:33
De l'ignorance ? Non je ne me permettrais pas : face à un tel chantier aucune question n'est stupide il y a trop d'enjeu et d'argent en jeu et je n'ai pas la prétention d'avoir la science infuse.
Excuse-moi effectivement j'aurai dû apporter des précisions concernant les noeuds en actif.
Tout les noeuds en actif ça permet de répartir la charge équitablement entre tout les serveurs ce qui les soulagent (toujours bon pour la pérennité du matos) et surtout leur laisse de la marge si un l'un d'eux venait à lâcher afin que ceux qui tournent encore puisque encaisser et se répartir le surplus d'activité auquel ils devraient faire face.
Petit exemple : les quatre (chiffre pour l'exemple) serveurs tournent à 60% de leurs capacités et l'un d'eux lâche, les trois serveurs qui tournent encore se répartissent alors l'activité du serveur qui a lâché. Résultat : trois serveurs qui tournent à 80% mais surtout aucun baisse de performance ou ralentis du trafic.
Et sinon un seul serveur actif, vu le nombre de clients connectés simultanément, c'est à proscrire d'une part car le serveur capable d'encaisser plusieurs millers de connections couterait plus cher que pleins de petits serveurs et d'autres part car si il venait à défaillir, même en admettant que les données soient préservées, une boite qui comptent 3000 à 4000 personnes qui ne peuvent plus bosser, ça présage du pire. ..
Excuse-moi effectivement j'aurai dû apporter des précisions concernant les noeuds en actif.
Tout les noeuds en actif ça permet de répartir la charge équitablement entre tout les serveurs ce qui les soulagent (toujours bon pour la pérennité du matos) et surtout leur laisse de la marge si un l'un d'eux venait à lâcher afin que ceux qui tournent encore puisque encaisser et se répartir le surplus d'activité auquel ils devraient faire face.
Petit exemple : les quatre (chiffre pour l'exemple) serveurs tournent à 60% de leurs capacités et l'un d'eux lâche, les trois serveurs qui tournent encore se répartissent alors l'activité du serveur qui a lâché. Résultat : trois serveurs qui tournent à 80% mais surtout aucun baisse de performance ou ralentis du trafic.
Et sinon un seul serveur actif, vu le nombre de clients connectés simultanément, c'est à proscrire d'une part car le serveur capable d'encaisser plusieurs millers de connections couterait plus cher que pleins de petits serveurs et d'autres part car si il venait à défaillir, même en admettant que les données soient préservées, une boite qui comptent 3000 à 4000 personnes qui ne peuvent plus bosser, ça présage du pire. ..
ybenaabud
Messages postés
10
Date d'inscription
mercredi 23 octobre 2002
Statut
Membre
Dernière intervention
17 décembre 2011
21 sept. 2011 à 19:16
21 sept. 2011 à 19:16
Parfait,
maintenant cette histoire de serveurs et de noeuds est très claire pour moi. tant que ce n'est pas le SAN qui tombe en panne, les serveurs font l'affaire.
passant maintenant à la question de backup, irt, spare...
supposant maintenant que le SAN principal tombe en panne (sinistre par exemple), d'après ce que j'ai compris j'aurai besoin, en plus d'un deuxième système SAN (back up) d'un autre serveur (spare), mais comment il est configuré pour prendre la main automatiquement après sinistre ? une sorte de miroring entre lui et les serveurs en clustering ? est ce que sql server seul peut assurer cette config ou bien j'aurai besoin d'un autre logiciel ?
synchro irt ? c'est quoi ?
Merci bcp d'avance :)
maintenant cette histoire de serveurs et de noeuds est très claire pour moi. tant que ce n'est pas le SAN qui tombe en panne, les serveurs font l'affaire.
passant maintenant à la question de backup, irt, spare...
supposant maintenant que le SAN principal tombe en panne (sinistre par exemple), d'après ce que j'ai compris j'aurai besoin, en plus d'un deuxième système SAN (back up) d'un autre serveur (spare), mais comment il est configuré pour prendre la main automatiquement après sinistre ? une sorte de miroring entre lui et les serveurs en clustering ? est ce que sql server seul peut assurer cette config ou bien j'aurai besoin d'un autre logiciel ?
synchro irt ? c'est quoi ?
Merci bcp d'avance :)
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Shu_Wong
Messages postés
36
Date d'inscription
samedi 20 août 2011
Statut
Membre
Dernière intervention
22 septembre 2011
5
22 sept. 2011 à 10:25
22 sept. 2011 à 10:25
Bonjour,
La reprise automatique d'activité d'un serveur de secours après que le serveur de prod ai lâché fait partie des fonctionnalités vendues en option avec les serveurs (à voir lors du devis). Attention cependant cela exigera sans doute une ligne spécialisée (qui coute la peau du cul). L'analogie avec le miroring est pertinente, c'est le principe de la synchro irt (in real time, en temps réel), les deux clusters sont synchro en permanence : celui de secours est une image du premier, de sorte que même si il n'est pas en prod, il est prêt à tout instant à prendre le relais étant données que les deux sont en temps réel
La reprise automatique d'activité d'un serveur de secours après que le serveur de prod ai lâché fait partie des fonctionnalités vendues en option avec les serveurs (à voir lors du devis). Attention cependant cela exigera sans doute une ligne spécialisée (qui coute la peau du cul). L'analogie avec le miroring est pertinente, c'est le principe de la synchro irt (in real time, en temps réel), les deux clusters sont synchro en permanence : celui de secours est une image du premier, de sorte que même si il n'est pas en prod, il est prêt à tout instant à prendre le relais étant données que les deux sont en temps réel
ybenaabud
Messages postés
10
Date d'inscription
mercredi 23 octobre 2002
Statut
Membre
Dernière intervention
17 décembre 2011
22 sept. 2011 à 10:41
22 sept. 2011 à 10:41
Pour la ligne spécialisé, ce ne sera pas nécessaire car le centre regroupe 10 bâtiments reliés par un réseau métropolitain. donc il me suffit de mettre le serveur dans un endroit éloigné du premier et puis c'est tout.
sinon, pour le serveur de backup, comment s'appelle l'option dont tu parle pour être sure de demander dans le devis le bon truc. et pour la configuration de la synchro irt, c'est juste du hardware ou bien du software aussi ? merci de m'expliquer un peu plus qu'est ce qui rentre en jeux pour faire cette configuration parceque c'est encore un peu confus pour moi :)
bonne journée !
sinon, pour le serveur de backup, comment s'appelle l'option dont tu parle pour être sure de demander dans le devis le bon truc. et pour la configuration de la synchro irt, c'est juste du hardware ou bien du software aussi ? merci de m'expliquer un peu plus qu'est ce qui rentre en jeux pour faire cette configuration parceque c'est encore un peu confus pour moi :)
bonne journée !
Shu_Wong
Messages postés
36
Date d'inscription
samedi 20 août 2011
Statut
Membre
Dernière intervention
22 septembre 2011
5
Modifié par Shu_Wong le 22/09/2011 à 13:35
Modifié par Shu_Wong le 22/09/2011 à 13:35
Ok pour la ligne spécialisée, le patron fera moins la gueule à l'addition (ptin 10 bâtiments et un MAN, c'est le Pérou ta boite) ^^.
Sinon pour l'option de reprise d'activité, ça s'appelle un "plan de continuité d'activité" lorsqu'il n'y a pas interruption de service (basculement automatique et presque instantané de l'activité sur le backup) ou "un plan de reprise d'activité" quand il y a interruption de service et qu'on souhaite repartir le plus vite possible. Ca se définit à l'achat du matos et du contrat de maintenance qui va avec.
Il faut regarder attentivement l'offre de chaque fournisseur potentiel: prix du matos bien sûr, mais aussi les types de contrats de maintenance à contracter si on souhaite bénéficier de certaines fonctionnalités comme un plan de continuité ou de reprise d'activité.
La synchro (ou réplication plus exactement) nécessite plusieurs choses: du matos avec idéalement les même références partout (du même fabricant donc) ou au minimum avec les même caractéristiques pour garantir la compatibilité et permettre la réplication, un paramétrage logiciel pour la configurer et la mettre en oeuvre et un réseau suffisamment fiable et performant pour la supporter.
Sinon pour l'option de reprise d'activité, ça s'appelle un "plan de continuité d'activité" lorsqu'il n'y a pas interruption de service (basculement automatique et presque instantané de l'activité sur le backup) ou "un plan de reprise d'activité" quand il y a interruption de service et qu'on souhaite repartir le plus vite possible. Ca se définit à l'achat du matos et du contrat de maintenance qui va avec.
Il faut regarder attentivement l'offre de chaque fournisseur potentiel: prix du matos bien sûr, mais aussi les types de contrats de maintenance à contracter si on souhaite bénéficier de certaines fonctionnalités comme un plan de continuité ou de reprise d'activité.
La synchro (ou réplication plus exactement) nécessite plusieurs choses: du matos avec idéalement les même références partout (du même fabricant donc) ou au minimum avec les même caractéristiques pour garantir la compatibilité et permettre la réplication, un paramétrage logiciel pour la configurer et la mettre en oeuvre et un réseau suffisamment fiable et performant pour la supporter.
ybenaabud
Messages postés
10
Date d'inscription
mercredi 23 octobre 2002
Statut
Membre
Dernière intervention
17 décembre 2011
22 sept. 2011 à 14:13
22 sept. 2011 à 14:13
Ok :)
lorsque tu dit réplication, tu veux dire la même réplication que fait SQL SERVER (abonnées, souscripteurs...etc) ou bien une autre ?
et puis est ce que tu me conseille un backup en cluster aussi (2 noeuds par exemple) ou pas besoin ?
lorsque tu dit réplication, tu veux dire la même réplication que fait SQL SERVER (abonnées, souscripteurs...etc) ou bien une autre ?
et puis est ce que tu me conseille un backup en cluster aussi (2 noeuds par exemple) ou pas besoin ?
Shu_Wong
Messages postés
36
Date d'inscription
samedi 20 août 2011
Statut
Membre
Dernière intervention
22 septembre 2011
5
22 sept. 2011 à 14:42
22 sept. 2011 à 14:42
La réplication en db est une des réplications informatiques existantes, dans le cas présent, ce serai plutôt de la réplication au niveau disque, plus détails ici:
https://fr.wikipedia.org/wiki/R%C3%A9plication_%28informatique%29
L'idéal pour le backup serait qu'il soit identique avec le cluster de prod mais si il est un peu moins touffu c'est pas trop grave, il faut simplement qu'il soit suffisamment performant pour encaisser l'activité à laquelle il doit pouvoir faire face dans l'éventualité où la totalité du cluster de prod serait foutue suite à un grave sinistre.
De plus ceux qui sont chargés de lâcher les thunes sont en général assez frileux à l'idée qu'il faut dépenser le double dans un investissement pour quelque chose dont l'utilité est incertaine : au bout de 5 ans sans sinistre avec un cluster de backup qui n'a jamais servi (c'est tout le mal que je te souhaite), c'est clairement de l'argent foutu en l'air pour un patron, alors lui en demander un autre, faut être bien burné car il te recevra pas avec le sourire.
https://fr.wikipedia.org/wiki/R%C3%A9plication_%28informatique%29
L'idéal pour le backup serait qu'il soit identique avec le cluster de prod mais si il est un peu moins touffu c'est pas trop grave, il faut simplement qu'il soit suffisamment performant pour encaisser l'activité à laquelle il doit pouvoir faire face dans l'éventualité où la totalité du cluster de prod serait foutue suite à un grave sinistre.
De plus ceux qui sont chargés de lâcher les thunes sont en général assez frileux à l'idée qu'il faut dépenser le double dans un investissement pour quelque chose dont l'utilité est incertaine : au bout de 5 ans sans sinistre avec un cluster de backup qui n'a jamais servi (c'est tout le mal que je te souhaite), c'est clairement de l'argent foutu en l'air pour un patron, alors lui en demander un autre, faut être bien burné car il te recevra pas avec le sourire.
ybenaabud
Messages postés
10
Date d'inscription
mercredi 23 octobre 2002
Statut
Membre
Dernière intervention
17 décembre 2011
22 sept. 2011 à 17:24
22 sept. 2011 à 17:24
très bien merci bcp,
je te mettrai au courant si tu veux de l'avancement :)
sinon le projet est pour un centre hospitalier universitaire contenant 10 hôpitaux et 5000 personnes travaillant dedans
je te mettrai au courant si tu veux de l'avancement :)
sinon le projet est pour un centre hospitalier universitaire contenant 10 hôpitaux et 5000 personnes travaillant dedans
Shu_Wong
Messages postés
36
Date d'inscription
samedi 20 août 2011
Statut
Membre
Dernière intervention
22 septembre 2011
5
22 sept. 2011 à 17:47
22 sept. 2011 à 17:47
Je t'en prie, c'était un plaisir.
N'hésite pas à me mettre au courant de l'avancement du projet (colossal) si tu le souhaite j'en serai ravi.
Bonne chance pour la suite.
N'hésite pas à me mettre au courant de l'avancement du projet (colossal) si tu le souhaite j'en serai ravi.
Bonne chance pour la suite.
ybenaabud
Messages postés
10
Date d'inscription
mercredi 23 octobre 2002
Statut
Membre
Dernière intervention
17 décembre 2011
22 sept. 2011 à 19:59
22 sept. 2011 à 19:59
On m'a dit que ça ne sert à rien de mettre plus d'un serveur en actif puisqu'à la fois il y a qu'un seul serveur qui peut exécuter des requêtes sur Sql Server à la fois !!
qu'est ce que tu pense ?
qu'est ce que tu pense ?
