Architecture voix et planification de la Haute Disponibilité avec Lync Server 2010

Présentation au sujet: "Architecture voix et planification de la Haute Disponibilité avec Lync Server 2010"— Transcription de la présentation:

1

2 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

3 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

4 Moyennes à grandes entreprises
Tous secteurs confondus Gouvernement

5 Avanade: A place to be 11 ans déjà!
Avanade a reçu le label « Top Employeurs France 2011 »

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

7 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

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

9 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

10 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

11 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: 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

12 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

13 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 »: Mise en cache des points de connexion Fqdns & IP: Registrar, Media Relay, MRAS Reconnections plus rapide (pas de redécouverte DNS)

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

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

16 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

17 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

18 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: NET NET: Nouveaux matériels gamme UX – migration date

19 Déploiement Simple et reproductible

20 Gestion Gestion centralisée Ajouts/modifications/suppressions

21 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)

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

23 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)

24 SBA: Connexion au Registar en mode nominal

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

26 SBA: Communications intra-site en mode nominal
Media SIP

27 SBA: Communications inter-site en mode nominal
Media SIP

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

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

30 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

31 Démo (rapide ) Perte SBA/SBS

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

33 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

34 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: Donner une réponse adaptée aux scénarios plausibles Définir les niveaux de service date

35 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

36 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.

37 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)

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

39 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

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

41 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

42 Cinématique de bascule

43 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

44 Pub! Un peu (d’auto) promo

45 Quelques liens MS Open Interoperability Program pour Lync Server 2010
Nexthop: Lync PowerShell: Blog de Jens Trier Rasmussen: Blog de Doug Deitterick: HAProxy (Soft-LB): Mon blog: Avanade:

46 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

47 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

48 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

49