Architecture voix et planification de la Haute Disponibilité avec Lync Server 2010 10 février 2011 Benoit Boudeville François Dorémieux CTO Architect Lync Product Group Avanade France Microsoft Corporation

A propos d’Avanade: Présent sur 61 sites dans 26 pays Chiffre d’affaires 2010 de US$953 million Plus de 20% de croissance annuelle depuis la création en 2000 Nos clients Plus de 2400 entreprises clientes 95%de clients satisfaits Nos services Des résultats concrets pour des entreprises de tous secteurs d’activité Support d’Accenture et Microsoft

Moyennes à grandes entreprises Tous secteurs confondus Gouvernement

Avanade: A place to be 11 ans déjà! Avanade a reçu le label « Top Employeurs France 2011 » http://www.topemployeurs.fr/TopEmployeursFrance/TopEmployeursFrance2011/C/tabid/5263/C/3/Avanade.aspx

Agenda Architectures résilientes et disponibles La résilience des sites distants Centres de Données et la résilience voix

Objectifs et éléments clés Objectifs de la session: Qu’est-ce qu’une architecture résiliente La résilience des sites distants (Branch Offices) La résilience des Centres de Données (Datacenters) Eléments clés: Les améliorations dans Lync Server 2010 permettent d’apporter une haute disponibilité des services voix/ToIP Les partenaires UC de Microsoft participent à la résilience de la voix aux utilisateurs de petits sites La résilience des Centre de Données permet d’assurer la disponibilité des services voix au travers de solutions géo-dispersées

Agenda Architectures résilientes et disponibles La résilience des sites distants Centres de Données et la résilience voix

Quoi de neuf dans Lync pour la haute disponibilité? Composant « Registrar » Effectue l’enregistrement des utilisateurs et le (re-)routage Chaque « Registrar » a sa base SQL (Express) « RTCLOCAL » La base gère aussi les réplicas du CMS Plusieurs Registrars possibles dans un déploiement Composant « User Services » Gestion de la présence Gestion des informations de conférence Utilise le back-end SQL « classique » Extrait Technet: Lync Server architecture has moved the registration and routing services onto individual front-end servers within a pool. User’s services (presence and so on) and conferencing are still in the back-end database. This means that in the event of a failure of the pool, the registration and routing services have a back-up provider. date

Quoi de neuf dans Lync pour la haute disponibilité? Architecture de base (vue simplifiée) Composant « User Services » (Présence & Infos de conférence) Composant « Registrar » Enregistrement et routage Enregistrement des utilisateurs Registrars et User Services sont co-localisés sur les frontaux Distribution des utilisateurs grâce à un algorithme de Hashage Evolutions: « Registrars locaux » Clients Lync

Et en details… Chaque utilisateur a un Registrar Primaire (Pool) Utilisation du DNS (SRV)  dirigés vers le Registrar primaire Mise en cache du Registrar Pool (EndpointConfiguration.cache) Utilisateurs sur un site central = site central Utilisateurs sur un site distant = Registrar local (SBA, SBS) Les utilisateurs s’enregistrent toujours auprès leur Registrar local, sauf s’il est indisponible Chaque Registrar peut avoir un Registrar de secours: Par exemple: SBA/SBS  secours vers Datacenter Le Registrar de secours teste périodiquement l’état de santé du(des) Registrars dont il est le secours Défaillance = Accepte les connexions (pas de redirection) Retour en mode nominal automatique après détection de remise en service = Notifie les clients (redirection) Délais configurables FailureDetectionInterval FailbackDetectionInterval Technet: http://technet.microsoft.com/en-us/library/gg398993.aspx The Registrar is perhaps the most important component in Microsoft Lync Server 2010; without a Registrar, users would not be able to log on to the system, and Lync Server 2010 would not be able to keep track of users and their current status. When a user logs on to Lync Server, the endpoint the user is logging on from (be it a computer, a mobile phone, or some other device) sends a REGISTER request to the registration server; in turn the server responds by challenging the client device for authentication credentials. If the client passes the challenge (that is, if the client presents a valid set of credentials), then the user is authenticated and endpoint information such as IP address, port, and user name is logged in the registration database. When a user logs off, this information is then removed from the database. In between log on and log off, the Registrar keeps status information up-to-date and helps to route messages to and from the user. date

Pool Registrar de secours Exemple d’architecture Data Center - Paris IM/Présence Conf Registrar AD & DNS Bob Pri: Paris Alice Pri: NY Sec: Paris Pool Registrar de secours Charlie Pri: SBA Sec: Paris Registrar SBA Site distant Data Center – New-York IM/Présence Conf Registrar AD & DNS

Autres nouveautés Support de la répartition de charge DNS pour les Pools Internes (EE) Attention: pas pour le trafic HTTP Clients  Serveurs HLB toujours requis, Windows NLB non supporté Solutions peu onéreuses: KEMP, Exceliance Gratuites: HAProxy et un peu d’huile de coude doigt But recherché: Réduction de la complexité Mode de mise hors service lente (« Draining ») jusqu’au redémarrage du serveur Résilience du dialogue (SDR UCMA 3.0) pour les conférences Si le Registrar de l’utilisateur tombe, ce dernier pourra tout de même participer à des conférences « What’s new in UCMA 3.0 »: http://msdn.microsoft.com/library/gg437208.aspx Mise en cache des points de connexion Fqdns & IP: Registrar, Media Relay, MRAS Reconnections plus rapide (pas de redécouverte DNS)

Agenda Architectures résilientes et disponibles La résilience des sites distants Centres de Données et la résilience voix

Options de déploiement Petit Site (<25 users) 25 WAN Data Center Site Moyen - (25-1000 utilisateurs) 500 Small Branch Appliance PSTN 1000 Gros Site (>1000 utilisateurs) Small Branch Server ou Serveur Standard + un Mediation Circuit Packet

Survivable Branch Appliances « SBA » Matériel dédié: Fournit la résilience des services de communication aux sites distants, « données » hébergées sur un Site Central Services multiples […] Services multiples: chaque vendeur UC a des solutions différentes, cf +2 slides date

Survivable Branch Appliances Haute disponibilité des services voix pour les sites distants Format compact / rackable / standardisé Vendues par des partenaires UC de Microsoft Gérées centralement depuis le Datacenter Composants Fonctionnalités Go-To Market Windows Server 2008 R2 Serveur de médiation Registrar Passerelle PSTN/RTC SIP Registrar Primaire/Secondaire SIP Proxy & Routage Connectivité PSTN/RTC Routage vers messagerie vocale Re-routage PSTN/RTC Gestion / Déclaration centralisée Jusqu’à 1000 utilisateurs OEM (Embedded channel) Partenaires Audiocodes Dialogic Ferrari HP NET

Survivable Branch Appliances Audiocodes: Mise à niveau des passerelles M1K et M2K Audiocodes Mediant 1000 –1U, 4E1/T1, alimentation redondante, passerelle multi-service/pare-feu (MSBG-Firewall), routage Mediant 2000 – 1U, alimentation redondante DMG 4000, 1U, 4 E1/T1, Redundant power supply Ferrari 1U, 4 E1/T1, Redundant Power supply HP Module SBA sur switchs Procurve E82xxx/E54xx. Alimentation redondante, 8 E1/T1, couche 2 UX Series. 1U, 8 E1/T1,Alimentation redondante. MSBG-Firewall, routage Dialogic: Réutilisation des DMG4000 Conversion en SBA (màj) Dialogic Ferrari: Mise à niveau des passerelles R2 en SBA HP: Conversion de switchs Procurve E8200 ou E5400 par ajout de module UC/Lync OIP: http://technet.microsoft.com/en-us/lync/gg131938.aspx#tab=3 NET NET: Nouveaux matériels gamme UX – migration date

Déploiement Simple et reproductible

Gestion Gestion centralisée Ajouts/modifications/suppressions

Support Maintenance et support fournis par le partenaire Mises à jour Windows Server 2008 R2 Peuvent être aussi gérées par le partenaire, ou Inscrites dans le cadre de gestion des mises à jour du client Mises à jour Lync Server 2010 Processus de qualification effectué par le partenaire, et Notification aux clients (validation, procédure)

Déploiement d’un Small Branch Server Démo Déploiement d’un Small Branch Server

SBA: Scénarii Plusieurs scénarii: mode nominal, perte du WAN, perte de la SBA SBA+WAN HS = variable (ex, connexion Internet locale via Edge envisageable)

SBA: Connexion au Registar en mode nominal

SBA: Connexion au Registar en cas de perte de WAN Déconnexion du UserPool Connexion locale maintenue (EndPoint Cache) Fonctionnalité restreintes

SBA: Communications intra-site en mode nominal Media SIP

SBA: Communications inter-site en mode nominal Media SIP

SBA: Communications intra-site (perte du WAN) Media SIP

SBA: Accès Edge en cas de perte de WAN & SBA HS Media SIP

SBA: Expérience utilisateur (perte du WAN) Fonctionnalités disponibles Authentification/Autorisation Contrôle des appels (pause, récup, …) Transfer/SimRing/Team/Délégués Appels entrants et sortants via PSTN Communications intra-site (P2P) Appels inter-site (PSTN) Conférences audio via PSTN Accès à la messagerie vocale (PSTN) Redirection vers Messagerie (DC) Call Detail Records (CDR) Fonctionnalités non disponibles Routage conditionnel lié à la présence (ex: DND) Connectivité inter-sites (IM, Partage d’applications, …) Conférences IM, Web, Vidéos Modification de présence Modification des paramètres de transfert d’appels Liste de contacts Groupes de réponse et listes d’attente

Démo (rapide ) Perte SBA/SBS

Agenda Architectures résilientes et disponibles La résilience des sites distants Centres de Données et la résilience voix

Résilience des Centres de Données Il faut imaginer les Pools comme des systèmes séparés, en définitive, il ne sont pas « liés » par nature Les clients effectuent des requêtes DNS de type SRV et A pour se connecter à un Pool; Lorsqu’une connexion est établie avec succès, ceux-ci sont redirigés vers leur Registrar Primaire (ou Secondaire) Les clients se connectent au Pool Secondaire si leur Pool Principal est indisponible: Il est nécessaire d’activer la bascule automatique et de configurer les délais de détection (Failover/Failback) Pour les clients ayant leur Pool Primaire en cache, la reconnexion prend un certain temps (timeout + redécouverte) Le retour arrière est automatique Pertes de fonctionnalités […] Le déploiement d’un Pool Director est hautement recommandé, et il devrait être presque obligatoire pour toute topologie Pertes de fonctionnalités = expliquées après date

Recouvrement sur désastre Burn DC, Burn… Central Management Store Remise en service du CMS sur Site Secondaire Le CMS peut rester inaccessible, cela ne perturbe pas le fonctionnement normal des serveurs Export-CsConfiguration  sauvegarde périodique de la configuration Export-CsLisConfiguration  sauvegarde Location Information Service Install-CsDatabase -CentralManagementDatabase  préparation DB Move-CsManagementServer  déplacement du CMS et LIS (forcé) Autres services Déplacement (forcé) des utilisateurs (optionnel) Import des données (DbImpExp) PRA / Réinstallation / Retour Procédure de déplacement du CMS: http://technet.microsoft.com/en-us/library/gg412921.aspx Donner une réponse adaptée aux scénarios plausibles Définir les niveaux de service date

Bascule inter-Pool/DC Processus de découverte Requête DNS: Connexion EndPointconfiguration cache Si pas de cache (ou Pool Primaire KO en #3-4-5), requête SRV, ex: _sipinternaltls.domaine.fr Réponse DNS: inclut les SRV du Pool Director (Resigtrar) et des autres Pools SRV { Host=sip.domaine.fr, Priority=0, Weight=0, Port=5061 }  Director ou Pool #1 SRV { Host=sip-failback.domaine.fr, Priority=10, Weight=0, Port=5061 } Connexion au Director  Si OK, Redirect vers Pool #1 (inclut Pool #2 en tant que Pool de Secours), si Director HS, tentative de connexion au 2nd SRV Si Pool #1 OK  connexion du client, récupération de la contact list, etc. Si Pool #1 KO  connexion du client au Pool #2

Bascule inter-Pool/DC Deux serveurs Edition Standard en pair Les pools peuvent éventuellement être primaire et secondaire l’un pour l’autre. Cependant, il restera toujours un certain nombre de limitations, comme dans l’exemple de topologie ci-dessus où l’accès au travers du Edge ne fonctionnera pas.

DC: Expérience utilisateur (bascule suite à parte du Pool Primaire) Fonctionnalités disponibles Authentification/Autorisation Contrôle des appels (pause, récup, …) Transfer/SimRing/Team/Délégués IM (P2P) Présence (Après le « move ») Communications intra-site (P2P) Communications inter-site (P2P) Accès aux conférences planifiées depuis le Pool Secondaire CDR Fonctionnalités non disponibles Pas de conférences via PSTN (Conferencing Auto Attendant) Planification de conférences IM, Web, A/V (plus de focus factory) Routage conditionnel lié à la présence (ex: DND) Modification des paramètres de transfert d’appels Liste de contacts Groupes de réponse et listes d’attente Messagerie vocale (réception) Consultation MV (via PSTN)

Résilience des Datacenters Démo Résilience des Datacenters

Environnement Site Central « DC1 » (Paris) 2 serveurs / Pool EE et son SQL, CMS Site distant « BE-BRX » (le SBS de la 1ère démo) Site Secondaire « FR-MAR » (Marseille) Serveur Standard Edition déjà déployé But: Configurer la bascule du site « FR-MAR » vers « DC1 » Observer une bascule Remise en service du Pool Principal date

Configuration Topology Builder Pour une SBA: FailureDetectionInterval = 120 FailbackDetectionInterval = 240

Cinématique de bascule 1. Le client est déconnecté, il tente de se reconnecter à son Registrar puis abandonne et effectue une redécouverte 3. Le client se reconnecte et est averti que certaines fonctionnalités ne seront pas disponibles 2. Pendant ce temps, le Registrar Pool de secours détecte la défaillance

Cinématique de bascule

Points à retenir Lync Server 2010 a été pensé pour améliorer sensiblement la résilience des services Le facteur « criticité » de la voix était souvent cité comme point faible des version précédentes Lync Server 2010 s’adapte aux besoins: Facilité de déploiement Facilité de gestion Nouvelles options: SBA/SBS Registrars Primaires et Secondaires « DNS load-balancing » Conseil: planifiez la mise en œuvre de Directors et d’enregistrements SRV priorisés afin d’optimiser les processus de bascule

Pub! Un peu (d’auto) promo

Quelques liens MS Open Interoperability Program pour Lync Server 2010 http://technet.microsoft.com/en-us/lync/gg131938.aspx#tab=3 Nexthop: http://blogs.technet.com/b/nexthop/ Lync PowerShell: http://blogs.technet.com/b/csps/ Blog de Jens Trier Rasmussen: http://blogs.technet.com/b/jenstr/ Blog de Doug Deitterick: http://blogs.technet.com/b/dodeitte/ HAProxy (Soft-LB): http://haproxy.1wt.eu/ Mon blog: http://unifiees.blogspot.com Avanade: http://www.avanade.com

Autres sessions Avanade A télécharger sur le portail des TechDays Windows Phone 7 sync application sur Azure  Création d’une application WP7 avec support d'un mode offline en utilisant le Sync framework et un stockage azure Mardi 8 Février 11H00 -12H00 L’application Lifecycle Management avec Visual Studio 2010  Fonctionnalités essentielles de la nouvelle version de la plateforme ALM basée sur Team Foundation Server 2010 et Visual Studio 2010 Mardi 8 février 14h30 – 15h30 Elastic Datacenter Vision du Datacenter Elastique d'Avanade,entre cloud privé et cloud public, intégrant la gestion unifiée du service infrastructure ou applicatif Mercredi 9 février 11h00 – 12h00

MSDN et TechNet : l’essentiel des ressources techniques à portée de clic Portail administration et infrastructure pour informaticiens Portail de ressources technique pour développeurs http://technet.com http://msdn.com

Script de configuration Bascule Pool Central  SE Begin { $Fqdn = "lyncpool.corp.uc-lab.org" $BackupRegistrarFqdn = "sv-lyncse.corp.uc-lab.org" Set-CsRegistrar -Identity "Registrar:$Fqdn" ` -BackupRegistrar $BackupRegistrarFqdn ` -EnableAutomaticFailover:$true ` -FailureDetectionInterval "00:00:30" ` -FailbackDetectionInterval "00:01:00" ` -Verbose Get-CsService -Identity "Registrar:$Fqdn" Enable-CsTopology } Le Topology Builder et les Cmdlets permettent de définir des intervalles < 60s, cependant à l’heure actuelle un valeur minimale de 60s est forcée dans le code