cluster sql server et ad ip

Bonjour,

J'ai une instance SQL Server 2008 R2 (sur W2008 R2) qui est configurée en cluster. Cette instance est pour l'instant active sur le noeud 1.
Sur le noeud, j'ai donc 3 adresses ip connues : ad ip du noeud, ad ip du cluster et ad ip de l'instance sql server (plus l'ad ip pour le heartbeat).

J'ai configuré database mail sur mon instance sql server (cluster). La passerelle SMTP se trouve en dehors de "notre" réseau et je dois donc passer par un firewall. Il faut donc autoriser mon instance SQL Server à envoyer des trames à la passerelle SMTP.

J'ai donc demandé à mon manager firewall d'ajouter l'ad ip de l'instance sql server dans le firewall (autoriser smtp). Mais ca n'a pas fonctionné. Il a fallu non pas autoriser l'ad ip de l'instance sql server (cluster) mais plutot l'ad ip du noeud (physique). Je pensais que vu que l'envoi de mails partait de database mail de l'instance sql server c'était l'ad ip du cluster sql server qui était pris en compte et non pas l'ad phyique du serveur.

Avez-vous une explication ?

S'il faut déclarer dans le firewall l'ad ip du noeud physique alors il faudra le faire pour tous les noeuds du cluster alors que sinon on pouvait se limiter à l'ad ip de l'instance sql server.

Par avance, merci pour vos explications.

Franck

Bonjour Franck,

Merci pour ce message, c'est tres interessant.

Database mail utilise un executable qui se trouve hors de l'instance SQL Server.
Tu peux le voir ici:
http://msdn.microsoft.com/en-us/library/ms189635.aspx
Je pense que de ce fait, c'est effectivement l'adresse IP du noeud qui est utilisee.
Si c'est effectivement le cas, il faudra alors autoriser toutes les adresses IP du cluster a passer par le firewall, sur le port specifique.

Pour eviter de devoir penser a cela a chaque fois qu'un noeud est ajoute au cluster, on peut penser a autoriser tous les hosts d'un subnet (dedie a votre cluster) a passer par le firewall sur le port specifique (A verifier avec un admin network si c'est possible).
Ca permettrai de garder une dissociation entre le physique (IP adresse en dur) et le logique (groupe d'IP pour le cluster).

Si tu as un retour d'experience la dessus, il est bienvenu !

Bonne journee,
Jerome

Bonjour Jerome,

Tout d'abord, merci pour ta réponse.
Je tiens à signaler que la qualité et la rapidité des réponses font de ce forum une aide précieuse pour moi.
:)

Effectivement, comme tu l'indiques, l'exe de database mail étant un process externe, cela semble expliquer la prise en compte de l'adresse ip du noeud.
Je vais pouvoir apporter une explication à mon manager network. Merci.

Je vais demander à mon manager network de définir l'ensemble des adresses des noeuds appartenant au cluster et tout devrait etre ok.

A bientot
;)

Franck

Databasemail est cluster-aware contrairement à son prédécesseur SQLMail.
Je pense (à vérifier) qu'il faut non pas mettre l'ip virtuel du cluster SQL mais l'ip virtuel du cluster Windows.

Citation:

---

Pour eviter de devoir penser a cela a chaque fois qu'un noeud est ajoute au cluster, on peut penser a autoriser tous les hosts d'un subnet (dedie a votre cluster) a passer par le firewall sur le port specifique (A verifier avec un admin network si c'est possible).

---

Personnellement je ne ferai pas cela pour des raisons de sécurité. Il suffit qu'une personne mal intentionnée puisse obtenir une IP du subnet en question il pourra envoyer tranquillement des mails depuis le réseau interne.

++

Bonjour David,

Merci pour ta réponse.
J'essaie de faire l'essai cet après-midi (en fonction de la disponibilité de mon manager network) et je vous fais un retour.

Je demanderai à mon manager network d'autoriser seulement l'ad ip de mon cluster windows.

A plus tard ...

Franck

David,

On vient de faire l'essai en autorisant l'adresse ip du cluster Windows dans le firewall mais cela n'a pas fonctionné.

essais :
. ad ip cluster windows autorisée dans firewall : envoi mail -> non
. ad ip cluster windows + ad ip cluster sql autorisées dans firewall : envoi mail -> non
. ad ip noeud physique autorisée dans firewall : envoir mail -> OK

Il semble donc que database mail s'appuie sur l'ad ip du noeud.

J'ai demandé à mon manager network d'ajouter les 3 ad ip (3 noeuds physiques pour notre cluster). Ainsi, je pense que tout sera ok.

Merci pour votre aide et à bientot

Franck

Merci pour le retour d'information.

Je pense que pour ce qui est de database mail qui est cluster aware, c'est qu'aucune autre modification en doit etre faite au niveau du serveur.
SQLMail avait besoin d'un client Outlook installe sur le serveur + un profil mappe (non standard avec une installation SQL Server), ce qui fait que cela devait etre configure pareil sur tous les noeuds, ce qui le rend moins "cluster aware".

Pour ce qui est du subnet, c'est une idee si jamais le cluster venait a grandir regulierement (ou pas)... Apres, il est tout a fait possible de limiter le nombre d'IP disponible pour le subnet et qui doit etre egal au nombre de noeud - 1 IP par noeud et un subnet de taille N noeud. (+2 IP du subnet + IP broadcast http://www.bradreese.com/how-to-subnet-a-network.pdf)
L'idee est - on rajoute un noeud, on extend la taille du subnet de 1 et on attribue la nouvelle IP au nouveau noeud.
Ensuite au niveau des firewall ca garanti la meme configuration pour tous les noeuds du cluster - Ca evite de se retrouver dans des situations bizarres en cas de failover ou le noeud qui recoit l'instance n'a pas les meme droits sur le reseau que le noeud precedent.

Je ne sais pas si c'est une best-practice niveau network et si le terme subnet est le bon (il est peut etre possible de definir des groupes d'IP et de garantir les memes droits a ces groupes), mais en tout cas ca me rappele l'utilisation d'un role de securite dans une base de donnees, ou l'attribution de droits a un groupe AD plutot qu'a un utilisateur pour ce qui est de la securite sur un folder ou serveur SQL - bref une distinction entre le physique et le logique afin de garantir que tous les membres physiques d'une meme entite logique beneficent exactement des memes droits.

Citation:

---

Je pense que pour ce qui est de database mail qui est cluster aware, c'est qu'aucune autre modification en doit etre faite au niveau du serveur.
SQLMail avait besoin d'un client Outlook installe sur le serveur + un profil mappe (non standard avec une installation SQL Server), ce qui fait que cela devait etre configure pareil sur tous les noeuds, ce qui le rend moins "cluster aware".

---

Disons que databasemail est capable de reprendre un envoi de mail lors d'un basculement de noeud (avec l'utilisation de service broker c'est tout de même plus facile). Après pour savoir si databasemail utilise réellement l'ip du cluster on pourrait mettre un sniffer de réseau sur un des noeuds (si j'ai le temps je ferai un test tiens) et regarder mais globalement je pense que la réponse de Frank confirme plutôt que c'est bien l'ip du noeud qui est utilisé.

Citation:

---

Pour ce qui est du subnet, c'est une idee si jamais le cluster venait a grandir regulierement... Apres, il est tout a fait possible de limiter le nombre d'IP disponible pour le subnet et qui doit etre egal au nombre de noeud - 1 IP par noeud et un subnet de taille N noeud.

---

Oui d'accord avec ca mais cela demande de jongler à chaque fois avec le plan d'adressage ip et le masque de sous réseau si je ne trompe pas .. est ce que c'est plus simple pour un admin réseau de faire cela plutôt que de rajouter / modifier une règle de firewall .. la question reste ouverte mais pour avoir vu la manipulation plus d'une fois je pense ne pas trop me tromper sur la réponse .. à voir donc :) De plus l'ajout d'un noeud de cluster se planifie suffisamment à l'avance (et reste une opération plutôt rare ...) pour pouvoir laisser le temps aux admins network de faire leur boulot.

Citation:

---

Je ne sais pas si c'est une best-practice niveau network, mais en tout cas ca me rappele l'utilisation d'un role de securite dans une base de donnees, ou l'attribution de droits a un groupe AD plutot qu'a un utilisateur pour ce qui est de la securite sur un folder ou serveur SQL - bref une distinction entre le physique et le logique afin de garantir que tous les membres physiques d'une meme entite logique beneficent exactement des meme droits.

---

Je dirai que tout dépend la ressource à protéger ... avoir un groupe plutôt qu'un utilisateur présente des avantages mais aussi des inconvénients en terme de sécurité même si globalement cela reste une bonne pratique. L'utilisation progressive des SID de services sur SQL Server plutôt que les groupes prédéfinis est un bon exemple.

++

David, Jerome,

Petite précision :
Demander à mon manager network d'ajouter les 3 adresses des noeuds (3 noeuds dans le cluster) est une opération relativement simple. Il a créé une autorisation dans le sens SQL vers SMTP en ajoutant au niveau source les 3 ad des noeuds. Ca semble le plus simple ... apparemment.

En tout cas, merci à tous les 2 pour votre aide précieuse.
:)

Franck

Mode clin d'oeil:
Je reste sceptique a ta parano sur l'utilisation de groupes. ;)

Effectivement, ca peut etre necessaire lorsqu'un niveau de securite tres eleve est requis.
Quand tu as une infra avec des milliers de serveurs, si a chaque fois tu dois repasser sur tous pour donner les memes droits a un nouveau DBA arrivant dans le groupe, ca prend un temps fou compare a l'ajouter dans un groupe AD! Note ca peut creer de l'emploi d'un autre cote ;)

Dans le cas d'un cluster, creer un groupe logique d'IP (subnet ou autre moyen (une OU specifique dans l'AD) - a voir avec les gars reseau/systeme) qui ont les memes droits te permet de garantir une consistence dans l'attribution des droits pour tous les noeuds sur les firewall des que le groupe est utilise plutot que le serveur physique.

Apres, il faut effectivement balancer le fait de mettre potentiellement un service critique down car un des noeuds n'a pas les meme droits qu'un autre sur un firewall X et que ton application ne fonctionne plus a cause de ca (et bonne chance aussi pour retrouver la source de l'erreur) et le potentiel trou de securite que quelqu'un de mal intentionne vienne ajouter une entree dans le groupe pour effectuer des taches nuisibles a l'entreprise.

Comme pour la plupart des choses, c'est ni blanc ni noir, juste une question de choix avec des avantages et des inconvenients.

Citation:

---

Effectivement, ca peut etre necessaire lorsqu'un niveau de securite tres eleve est requis.
Quand tu as une infra avec des milliers de serveurs, si a chaque fois tu dois repasser sur tous pour donner les memes droits a un nouveau DBA arrivant dans le groupe, ca prend un temps fou compare a l'ajouter dans un groupe AD! Note ca peut creer de l'emploi d'un autre cote

---

Dans ce cas il est évident que d'avoir un seul point de mis à jour reste la meilleure solution. Je ne suis pas contre les groupes bien au contraire pour les mêmes raisons que tu cites plus haut.

Citation:

---

Dans le cas d'un cluster, creer un groupe logique d'IP (subnet ou autre moyen (une OU specifique dans l'AD) - a voir avec les gars reseau/systeme) qui ont les memes droits te permet de garantir une consistence dans l'attribution des droits pour tous les noeuds sur les firewall des que le groupe est utilise plutot que le serveur physique.

---

Le problème de groupe dans ce cas (je précise) reste pour moi un inconvénient majeur si on entend par groupe un ensemble d'ip réservé à l'avance pour un groupe d'ordinateurs. Si toutes ces IP sont réservés et non utilisés cela laisse une brèche en terme de sécurité. Rien ne garantit que quelqu'un ne pourra pas s'en servir par la suite. C'est un peu comme les ports physiques d'un switch non utilisés et qui restent potentiellement actifs ... Sur le firewall on aura bien entendu ajouter une règle au niveau du groupe d'adresses ..

Citation:

---

Comme pour la plupart des choses, c'est ni blanc ni noir, juste une question de choix avec des avantages et des inconvenients.

---

Là on est bien d'accord ... ca donne justement l'occasion de débattre sur certains points .. ce qui reste intéressant :)

Citation:

---

Petite précision :
Demander à mon manager network d'ajouter les 3 adresses des noeuds (3 noeuds dans le cluster) est une opération relativement simple. Il a créé une autorisation dans le sens SQL vers SMTP en ajoutant au niveau source les 3 ad des noeuds. Ca semble le plus simple ... apparemment.

---

Oui je confirme pour l'avoir fait lorsque j'étais pseudo admin système :)

Petite précision moi aussi (apès avoir vérifié certaines informations) :

Toutes les communications TCP au niveau du cluster SQL écoutent sur l'IP virtuel alors que la réponse s'effectue en utilisant l'ip physique du noeud courant d'où cette petite confusion à prendre en compte au niveau du réglage du firewall.

++

Citation:

---

Envoyé par mikedavem

Le problème de groupe dans ce cas (je précise) reste pour moi un inconvénient majeur si on entend par groupe un ensemble d'ip réservé à l'avance pour un groupe d'ordinateurs. Si toutes ces IP sont réservés et non utilisés cela laisse une brèche en terme de sécurité. Rien ne garantit que quelqu'un ne pourra pas s'en servir par la suite. C'est un peu comme les ports physiques d'un switch non utilisés et qui restent potentiellement actifs ... Sur le firewall on aura bien entendu ajouter une règle au niveau du groupe d'adresses ..

---

Les petits gars du network ils peuvent pas faire ca en dynamique (contre une ptite biere :D) ? ;)
L'idee ici, plutot que le moyen, est de s'assurer que tous les noeuds du meme cluster aient exactement les memes permissions sur l'ensemble de l'infrastructure. Pour ce faire, creer une entite logique et assigner les droits a celle-ci.
Des que l'on doit modifier/definir des permissions concernant le cluster a quelque niveau que se soit plutot, le faire en utilisant cette entite plutot que de le faire pour chaque noeud.

Effectivement, ca cree de chouettes debats ;)

Si tu parles d'OU et de permissions au niveau des objets d'ordinateurs pour les noeuds du cluster on est sur la même longueur d'onde ;)

++

OU dans l'AD, apres au niveau firewall je sais pas comment on peut faire ca - Je pensais a un subnet mais si ca tombe c'est juste un groupe Cisco ou alors tu utilises une OU de l'AD.

Y a un quelqu'un qui fait du reseau dans le coin qui peut nous dire comment faire ? :)

David,

Quand tu dis :
"Toutes les communications TCP au niveau du cluster SQL écoutent sur l'IP virtuel alors que la réponse s'effectue en utilisant l'ip physique du noeud courant d'où cette petite confusion à prendre en compte au niveau du réglage du firewall."

Cela concerne que database mail ou sql server en "général" ?

Je m'explique ...

Récemment, je devais accéder à un cluster sql server "éloigné" via SSMS. Je devais donc passé par un firewall. Après avoir autorisé l'adresse ip du cluster sql server, ca ne marchait pas. Après quelques recherches, jeme suis apercu qu'il fallait autoriser l'ad ip du noeud.

Voir lien http://support.microsoft.com/kb/318432/fr

"Si vous exécutez une trace réseau sur le serveur, vous pouvez voir que le serveur reçoit réellement la requête de l'ordinateur client sur le port UDP 1434 pour l'adresse IP de serveur virtuel ; toutefois, la réponse est envoyée avec l'adresse IP physique du nœud de cluster est en cours d'exécution SQL Server.

Lorsque le serveur renvoie les informations, le cadre de réseau contient l'adresse IP du nœud physique au lieu de l'adresse IP du serveur virtuel. Selon la configuration du pare-feu, ce paquet réseau peut être supprimé, et le client ne peut pas recevoir les réponses.

Ce problème est résolu dans les cas suivants :
Microsoft SQL Server 2008 sur Windows Server 2008
Microsoft SQL Server 2005 coexiste avec SQL Server 2008 sur Windows Server 2008
Ce problème se produit dans SQL Server 2008 sur Windows Server 2003.
"
J'en avais déduit que le serveur que je devais contacté devait certainement etre concerné par ce bug.

Ma question est donc :
. si j'ai un cluster sql server 2008 R2 sur w2008 R2 (ce qui est mon cas) et que des clients doivent se connecter sur ce cluster sql server via un firewall, est-ce que les requetes envoyés par les clients vont revenir avec l'adresse ip du cluster sql ou l'adresse ip du noeud ?

Je pensais que lorsqu'on envoyait une trame avec une certaine adresse (ad cluster sql server dans notre cas) alors la réponse revenait avec cette adresse.
Que ce ne soit pas le cas pour database mail, je comprends car il ne fait pas "appel" au cluster sql mais il "appartient' plutot aux composants fournis par SQL Server. Mais pour une connexion au cluster sql server en tant que client, ca me "gene" un peu plus.

Merci pour la confirmation sur ce point.

Franck

Non ca ne concerne que databasemail dans ton cas.
Les trames de communication sur l'instance en cluster sont bien renvoyées avec la bonne adresse IP. On avait également un souci avec SQL Browser qui n'est pas cluste aware (IP_ANY) et qui renvoyait la mauvaise adresse du noeud. Problème qui est résolu depuis 2008.

J'ai fait un petit test avec wireshark concernant databasemail et c'est bien l'ip du noeud physique qui répond dans ce cas.

++