#JSS2015
Les journées
SQL Server 2015
Un événement organisé par GUSS
@GUSS_FRANCE
#JSS2015
Les journées
SQL Server 2015
Un événement organisé par GUSS
Infrastructure BI #4
Le Scale Out
Mathias Ekizian- Mi...
La communauté Data & BI Microsoft
Webcasts, Conférences, Afterworks
http://GUSS.pro
Session donnée pour
@GUSS_FRANCE
/GUSS...
#JSS2015
Merci à nos sponsors
#JSS2015
Infrastructure BI, 4ème épisode !
JSS 2012 – Les infrastructures mutualisées JSS 2013 – Les technologies In-Memor...
#JSS2015
• Problématiques et Enjeux
• Le principe du Scale Out
• L’équilibrage de charge
• Reporting Services
• SharePoint...
#JSS2015
Problématiques et Enjeux
#JSS2015
Les enjeux pour les organisations
 La compétitivité, la croissance
 Capacité à comprendre, décider et opérer da...
#JSS2015
La consommation et le traitement de l’information est au centre de ces
problématiques.
Les applications et les se...
#JSS2015
Les enjeux pour l’IT
 La Qualité du Service (QoS)
 La prédictibilité des performances
 L’évolutivité et l’élas...
#JSS2015
Le principe du Scale Out
#JSS2015
Le principe du Scale Out
Configuration
“standard” Scale Up Scale Out
#JSS2015
Le principe du Scale Out
• Repose sur des configurations unitaires, généralement standardisées,
et imbriquées dan...
#JSS2015
La montée en charge avec le Scale Out
#JSS2015
Les spécificités de la Business Intelligence
• Des services généralement consommateurs en ressources (CPU, RAM
et...
#JSS2015
L’orientation vers le Cloud
Les services et technologies Cloud sont alignés avec ces besoins et enjeux :
• Capaci...
#JSS2015
L’équilibrage de charge
#JSS2015
L’équilibrage de charge
Scale
Out
Ferme de serveurs
Nom
DNS
Accès utilisateur
Répartiteur
de charge
#JSS2015
• Les accès utilisateurs sont distribués sur les différents serveurs de la ferme
• Le point d’entrée est un nom D...
#JSS2015
Les méthodes de répartition
• Round-Robin
• Round-Robin, pondéré
• Affinité de session TCP-IP
• Affinité par cook...
#JSS2015
Les solutions matérielles
Solution privilégiée pour les applications critiques
Ex :
• F5 BIGIP
• Radware Alteon
•...
#JSS2015
Les solutions logicielles
• Network Load Balancing Windows Server
• Load Balancing DNS en Round Robin
• Solutions...
#JSS2015
Scale Out avec
Reporting Services
#JSS2015
• Seule la version Enterprise de Reporting Services prend en charge nativement le
Scale Out du service de reporti...
#JSS2015
Déploiement SSRS standard
25
• Le service de rapports et l’instance de base de données (catalogue SSRS)
sont exéc...
#JSS201526
Déploiement SSRS en Scale Out
#JSS201527
Déploiement SSRS standard en Scale Out
• Fermes de frontaux SSRS en Scale Out
• Bases Reporting Services sur se...
#JSS201528
Déploiement SSRS en Scale Out et HA SQL
#JSS2015
Scale Out avec
SharePoint BI
#JSS201530
Evolutivité de la ferme SharePoint
3 – Extension de la ferme en Scale Out avec ajout de frontaux web
multiples ...
#JSS2015
Ferme SharePoint 3 tiers
Couche Web
Couche Applicative
Couche Données
Répartition de charge (hors SPS)
Frontaux W...
#JSS2015
Load Balancing des frontaux SharePoint 2013
• SharePoint repose sur une infrastructure Claims pour authentifier l...
#JSS2015
Load Balancing Interne SharePoint
SharePoint dispose nativement d’un mécanisme d’équilibrage des services
d’appli...
#JSS2015
Load Balancing Excel Calculation Services
Paramètre du Load Balancing ECS au niveau du service d’application.
Les...
#JSS201536
Ferme SharePoint 2013
Frontaux Web
Clients
Serveurs Applicatifs
Bases SQL Server
Base
Config.
Bases
Contenu
Bas...
#JSS2015
Scale Out avec
Analysis Services
#JSS2015
Les principes du Scale Out avec Analysis Services
• 1 Instance de process
• N Instances de requêtes en lecture
se...
#JSS2015
Synchronisation de base SSAS par XMLA
• Natif depuis SQL Server AS 2005
• Synchronisation d’une instance cible en...
#JSS2015
Attachement et détachement des bases SSAS
Attachement en
lecture seule
sur LUN partagé
Serveurs de requêtes
• Nat...
#JSS2015
Synchronisation des données par Switch de LUNS
Scale-Out Querying for Analysis Services with Read-Only Databases
...
#JSS2015
Le Robocopy avec Windows Server 2012
ROBOCOPY s’appuie sur le protocole « Server Message Block » (SMB) en version...
#JSS2015
Exemple de mécanisme de synchronisation par
Robocopy
#JSS2015
Scale Out avec
SQL Server
#JSS2015
Utilisation des réplicats AlwaysOn en lecture seule
46Microsoft Confidential
A
A
A
A
Mouvement asynchrone
A
A
Rép...
#JSS2015Microsoft Confidential
Les groupes de disponibilité AlwaysOn
Windows Server Failover Cluster
Unité de
haute
dispon...
#JSS2015Microsoft Confidential
La combinaison des réplicats
Windows Server Failover Cluster
AG1 AG1 AG1 AG1
AG1
….
A
Répli...
#JSS2015
• SQL Server Management Studio
• Transact-SQL
• PowerShell
Configuration des réplicats en lecture seule
#JSS2015
Le Listener
Constitue le point d’entrée à partir duquel les clients vont se connecter
- Inclut : nom réseau, adre...
#JSS2015Microsoft Confidential
Configuration du routage en lecture seule
ALTER AVAILABILITY GROUP
- Routing URL
- URL et p...
#JSS2015
Démo : Load Balancing des réplicats
secondaires avec SQL Server 2016
#JSS2015#JSS2015
Les évaluations des sessions,
c’est important !!
http://GUSS.Pro/jss
#JSS2015
Merci à nos volontaires…
#JSS2015#JSS2015
Prochain SlideShare
Chargement dans…5
×

[JSS2015] Infra bi#4 - le scale out

505 vues

Publié le

Nous vous proposons pour ce 4ème épisode de notre série « Infrastructures BI @JSS », un focus sur les techniques de mise à l’échelle horizontale « Scale Out » des plateformes décisionnelles.
Les besoins toujours croissants des organisations (nombre d’utilisateur simultanés, fraicheur des données, extension des domaines fonctionnels…) nécessitent de concevoir des architectures en mesure de répondre à ces attentes, pour une montée en charge optimale.
La session traitera des différentes couches que nous retrouvons dans les architectures décisionnelles (datamarts, analyse, reporting…), sans oublier d’évoquer SQL Server 2016 qui apporte des nouveautés significatives en matière de Scale Out !

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
505
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Round-Robin : C'est l'algorithme le plus simple, une requête est envoyée au premier serveur, puis une au second, et ainsi de suite jusqu'au dernier, puis un tour est recommencé avec une première requête au premier serveur, etc.
    Round-Robin pondéré : Les serveurs de poids fort prennent les premières requêtes et en prennent davantage que ceux de poids faible.
    Moins de connexion : Assigne davantage de requêtes aux serveurs en exécutant le moins.
    Moins de connexion, pondéré : Assigne davantage de requêtes aux serveurs en exécutant le moins en tenant compte de leur poids.
    Hachage de destination : Répartit les requêtes en fonction d'une table de hachage contenant les adresses IP des serveurs.
    Hachage de source : Répartit les requêtes en fonction d'une table de hachage basée sur les adresses IP d'où proviennent les requêtes.
  • How to Configure View State Validation
    To run a scale-out deployment on an NLB cluster, you must configure view state validation so that users can view interactive HTML reports. You must do this for the report server and for Report Manager.
    View state validation is controlled by the ASP.NET. By default, view state validation is enabled and uses the identity of the Web service to perform the validation. However, in an NLB cluster scenario, there are multiple service instances and web service identities that run on different computers. Because the service identity varies for each node, you cannot rely on a single process identity to perform the validation.
    To work around this issue, you can generate an arbitrary validation key to support view state validation, and then manually configure each report server node to use the same key. You can use any randomly generated hexadecimal sequence. The validation algorithm (such as SHA1) determines how long the hexadecimal sequence must be.
    Generate a validation key and decryption key by using the autogenerate functionality provided by the .NET Framework. In the end, you must have a single <machineKey> entry that you can paste into the Web.config file for each Report Manager instance in the scale-out deployment.
    The following example provides an illustration of the value you must obtain. Do not copy the example into your configuration files; the key values are not valid.
    Copy
    <machineKey validationKey="123455555" decryptionKey="678999999" validation="SHA1" decryption="AES"/>
  • SharePoint 2013 use claims infrastructure and the new Distributed Cache Service to store login tokens, load balancer affinity is no longer reuiqred for SharePoint 2013 farm because of this dedicated cahe service.
  • Workbook : effet de cache, jusqu’à la republication du classeur
    Round Robbin : rotation des requêtes sur les différentes > interessant pour les classeur à traitement couteux et complexe
    Local : exécution locale sur le frontal web recevant la requête > interresant pour la perf, mais chargement N fois du même classeur, risque potentiel sur la scalabilité
  • Préconisation pour SSAS : affinité au niveau de la session TCP-IP de l’utilisateur. Faire en sorte qu’un utilisateur soit redirigé vers le même serveur SSAS > application du cache.
    L’ utilisateur pourra éventuellement avoir différentes connection sur ce même serveur.
  • Here are some important factors to consider when you work with synchronization:
    At the end of the synchronization process, a Write lock must be applied to the target server. If this lock is queued up behind a long running query, it can prevent users from querying the target database.
    During synchronization, a read commit lock is applied to the source server, which prevents users from processing new data but allows multiple synchronizations to occur from the same source server.
    For enterprise-size databases, the synchronization method can be expensive and low-performing. Because some operations are single-threaded (such as the delete operation), having high-performance servers and disk subsystems may not result in faster synchronization times. Because of this, we recommended that for enterprise size databases you use alternate methods, such as Robocopy (discussed later in this guide) or hardware-based solutions (for example, SAN clones and snapshots).
  • Les captures instantanées (Snapshots) sont exposées en tant que volume aux instances de requêtes.

    Les instances de requêtes s’attachent en lecture seule.

    Il n’est pas nécessaire d’appliquer une mécanisme de synchronisation au niveau des données.

    Point d’attention concernant la gestion de la fragmentation disque.

    Le mécanisme de gestion des captures instantanées doit nécessairement être intégré dans la chaine applicative.
  • 3 LUNS :

    Lun de process

    Lun de requête

    Lun de standby (swap progressif sur chaque nœud du cluster)

    Swap des nœuds entre Lun de requête et Lun de standby

    Attachement multiple du Lun de requête sur les serveurs de requêtes, en lecture seule

    Sortie temporaire et séquentielle du cluster NLB pour chaque serveur de requêtes


    read-only database shared between multiple query servers:
    Copying the updated database   The processing server updates the cube's dimensions and facts as usual. After all cube processing finishes, it is possible to detach the database from the processing server, copy it to the Standby DB LUN, and then reattach the database on the processing server.
    Write-protecting the standby volume   Before swapping Standby DB and Query DB LUNs on query servers, it is necessary to configure the standby NTFS partition as a read-only volume by using the Diskpart command-line tool that ships with Windows Server 2008. Run diskpart.exe, type list volume to determine the correct volume number, then type select volume <volume number> to select the standby volume, and then use attributes volume set readonly to write-protect the standby volume.
    Swapping databases on query servers   Now that the standby volume is write-protected, you can swap the standby and query databases. Exclude the desired query server from load-balancing and, after draining all users, detach the current read-only database, dismount the Query DB LUN, mount the Standby DB LUN instead, and then attach the new database copy in read-only mode. If you manually attach the database in SQL Server Management Studio, make sure you select the Read-only check box in the Attach Database dialog box. For automated methods, refer to the SQL Server 2008 Books Online topic “Switching an Analysis Services database between ReadOnly and ReadWrite modes” at http://msdn.microsoft.com/en-us/library/cc280661.aspx.
    Swapping LUNs on the processing server   Upon completion of the LUN swap on all query servers, dismount the Standby DB LUN on the processing server, and then mount the previous Query DB LUN and enable write access so that the previous Query DB LUN can now act as the Standby DB LUN. Run diskpart.exe, type list volume to determine the volume number, type select volume <volume number> to select the volume, and then type attribute clear readonly to remove the read-only flag.
  • Réplicat secondaire
    Full copy only
    Pas de diff
    Only

    Respecter la chaine

    Attention à la chaine
    Le plus important c’est l’espace


    Requete sur le secondaire en read comitted snaphsot
    Les requetes sur le secondaire > les stats sont crées dans tempfb (tempo) > ces statistiques sont perdues si le groupe de disponibilité bascule sur un autre noeud

    Les statistiques sont mis à jour où l’on fait des update/delete/select (clause where)
  • The image shows a standalone SQL Server instance configured as a Primary Replica of an Availability Group (A) with a Synchronous Secondary Replica configured at another standalone SQL Server instance.

    An availability group is a WSFC resource group. It defines a set of failover partners known as replicas: a primary replica and one or more secondary replicas. A replica is the location of one or more availability databases that are defined in the availability group.

    Although availability groups use WSFC, they do not require the SQL Server instance be clustered. Instead, they use WSFC resource health detection and failover capabilities to manage a group of databases.

    For additional information refer to “Overview of AlwaysOn Availability Groups (SQL Server)” (http://msdn.microsoft.com/en-us/library/ff877884.aspx#FormsOfFailover).
  • The image shows a standalone SQL Server instance configured as a primary replica of an Availability Group (A) with two synchronous secondary replicas configured at two standalone SQL Server instance and six asynchronous secondary replicas configured at six other standalone SQL Server instances.

    You can specify from one to nine instances of SQL Server to host availability replicas in the new availability group. At the least, you must specify your local server instance, which becomes the initial primary replica. If you want, you can also specify up to eight secondary replicas. The server instances that host the availability replicas must reside on different WSFC nodes within the same Windows Server cluster.

    Max # of Primary Replica 1
    Max # of Secondary Replicas 8
    Max synchronous secondary replicas 2
    Max synchronous replicas 3 (including primary)
    Max automatic failover replicas 2 (primary and one secondary)
  • Readable Secondary Options
    Readability behavior of a Secondary database is controlled by 3 different options configurable for each replica
    No
    No user connections are allowed to secondary databases of this replica. They are not available for read access. This is the default setting.
    Yes
    All connections are allowed to secondary databases of this replica, but only for read access. The secondary database(s) are all available for read access.
    Read-intent only
    Only those connections with a specific application intent property will be allowed access. The secondary database(s) are all available for read access.


    Availability Group Listener
    Availability group listeners direct incoming connections to the primary replica or to a read-only secondary replica.

    An availability group listener enables the client to connect to a replica without needing to know the name of the physical instance of SQL Server that it is connecting to. You do not need to modify the client-connection string in order to connect to the current location of a primary replica. If a primary replica is switched to being a secondary replica, the clients need only to reconnect to the availability group listener, and then SQL Server automatically directs the client to the instance of SQL Server that hosts the primary replica.

    An availability group listener consists of a listener DNS name, listener port designation, and one or more IP addresses. Availability group listeners rely on WSFC in order to redirect client connections in the event of local or remote failures of an availability group. When you create a new availability group listener, it becomes a resource in a cluster with an associated virtual network name (VNN), virtual IP (VIP), and availability group dependency.

    For a given availability group you can create an availability group listener. Only the TCP protocol is supported. Also, the DNS name of the listener must be unique in the domain and in NetBIOS.

    Each availability group listener directs client connections either to the primary replica or to a read-only secondary replica. If the primary replica goes offline on one instance of SQL Server and comes online on another instance of SQL Server, the availability group listener redirects client connections to the new primary replica. Also, any read-only connections to the new primary replica are directed to another secondary replica if any is configured to accept client connections. Secondary replicas must be configured to accept incoming connections, and routing must be configured accordingly.
  • Availability Group Listener
    Availability group listeners direct incoming connections to the primary replica or to a read-only secondary replica.

    An availability group listener enables the client to connect to a replica without needing to know the name of the physical instance of SQL Server that it is connecting to. You do not need to modify the client-connection string in order to connect to the current location of a primary replica. If a primary replica is switched to being a secondary replica, the clients need only to reconnect to the availability group listener, and then SQL Server automatically directs the client to the instance of SQL Server that hosts the primary replica.

    An availability group listener consists of a listener DNS name, listener port designation, and one or more IP addresses. Availability group listeners rely on WSFC in order to redirect client connections in the event of local or remote failures of an availability group. When you create a new availability group listener, it becomes a resource in a cluster with an associated virtual network name (VNN), virtual IP (VIP), and availability group dependency.

    For a given availability group you can create an availability group listener. Only the TCP protocol is supported. Also, the DNS name of the listener must be unique in the domain and in NetBIOS.

    Each availability group listener directs client connections either to the primary replica or to a read-only secondary replica. If the primary replica goes offline on one instance of SQL Server and comes online on another instance of SQL Server, the availability group listener redirects client connections to the new primary replica. Also, any read-only connections to the new primary replica are directed to another secondary replica if any is configured to accept client connections. Secondary replicas must be configured to accept incoming connections, and routing must be configured accordingly.
  • Primary plays an important role in the Read-only routing. When an application connection connects via Listener with an intent as Read-only, Primary responds back with the Routing URL of the next available Secondary based on the Routing List.

    Since all read-only connections need to be routed through Primary, Routing will fail if the Primary is either not available or disconnected from the Secondary replicas.
  • On parlait des speakers, il y a une chose qui leur tient à cœur !
  • [JSS2015] Infra bi#4 - le scale out

    1. 1. #JSS2015 Les journées SQL Server 2015 Un événement organisé par GUSS @GUSS_FRANCE
    2. 2. #JSS2015 Les journées SQL Server 2015 Un événement organisé par GUSS Infrastructure BI #4 Le Scale Out Mathias Ekizian- Microsoft Antoine Richet - Microsoft
    3. 3. La communauté Data & BI Microsoft Webcasts, Conférences, Afterworks http://GUSS.pro Session donnée pour @GUSS_FRANCE /GUSS /GUSS.FR #JSS2015 Les journées SQL Server 2015
    4. 4. #JSS2015 Merci à nos sponsors
    5. 5. #JSS2015 Infrastructure BI, 4ème épisode ! JSS 2012 – Les infrastructures mutualisées JSS 2013 – Les technologies In-Memory JSS 2014 – L’authentification BI JSS 2015 – Le Scale Out
    6. 6. #JSS2015 • Problématiques et Enjeux • Le principe du Scale Out • L’équilibrage de charge • Reporting Services • SharePoint BI • Analysis Services • SQL Server • APS • SQL Azure DWH Agenda
    7. 7. #JSS2015 Problématiques et Enjeux
    8. 8. #JSS2015 Les enjeux pour les organisations  La compétitivité, la croissance  Capacité à comprendre, décider et opérer dans un contexte concurrentiel et évolutif  Capacité des équipes opérationnelles à s’approprier les solutions  Contribuer à la transformation numérique de l’entreprise Problématiques et enjeux
    9. 9. #JSS2015 La consommation et le traitement de l’information est au centre de ces problématiques. Les applications et les services qui ouvrent l’accès à ces informations doivent être :  Hautement disponibles  Rapides (temps de réponse)  Ouvertes à de nouveaux utilisateurs  Extensibles (nouveaux périmètres fonctionnels)  Temps réel ou semi temps-réel Problématiques et enjeux
    10. 10. #JSS2015 Les enjeux pour l’IT  La Qualité du Service (QoS)  La prédictibilité des performances  L’évolutivité et l’élasticité des architectures  Les coûts matériels et opérationnels  Le besoin de stockage  Les données sous toute ses formes Problématiques et enjeux
    11. 11. #JSS2015 Le principe du Scale Out
    12. 12. #JSS2015 Le principe du Scale Out Configuration “standard” Scale Up Scale Out
    13. 13. #JSS2015 Le principe du Scale Out • Repose sur des configurations unitaires, généralement standardisées, et imbriquées dans une ferme de serveurs • Extension de la capacité de traitement par superposition de ce type de configuration • Répartition horizontale de la charge de travail • Disponibilité et capacité de montée en charge à travers la ferme de serveurs en « scale out » • Principe de linéarité de la capacité de montée en charge
    14. 14. #JSS2015 La montée en charge avec le Scale Out
    15. 15. #JSS2015 Les spécificités de la Business Intelligence • Des services généralement consommateurs en ressources (CPU, RAM et IO) • Différents types d’usages • Reporting de Mass • Analyse Ad-Hoc • BI en libre service • Accès aux données principalement en lecture seule • Les services analytiques gèrent des sessions utilisateurs, et de nombreux niveaux de cache • Traitement des données (alimentation) généralement par batchs
    16. 16. #JSS2015 L’orientation vers le Cloud Les services et technologies Cloud sont alignés avec ces besoins et enjeux : • Capacité de traitement et stockage quasi infinies • Elasticité des infrastructures • Automatisation de provisionnement • Solutions de répartition de charge natives • Progression des solutions hybrides (combinaison OnPremise et Azure) • Coût en fonction de l’usage
    17. 17. #JSS2015 L’équilibrage de charge
    18. 18. #JSS2015 L’équilibrage de charge Scale Out Ferme de serveurs Nom DNS Accès utilisateur Répartiteur de charge
    19. 19. #JSS2015 • Les accès utilisateurs sont distribués sur les différents serveurs de la ferme • Le point d’entrée est un nom DNS utilisé par le mécanisme d’équilibrage de charge • La répartition de la charge s’accompagne généralement d’une détection de l’état de santé de chaque noeud • Différentes configurations et solutions sont disponibles sur le marché L’équilibrage de charge
    20. 20. #JSS2015 Les méthodes de répartition • Round-Robin • Round-Robin, pondéré • Affinité de session TCP-IP • Affinité par cookie • Moins de connexions • Moins de connexions, pondéré • Hachage de source • Hachage de destination
    21. 21. #JSS2015 Les solutions matérielles Solution privilégiée pour les applications critiques Ex : • F5 BIGIP • Radware Alteon • Cisco ACE Ces solutions offrent des fonctionnalités avancées : • Monitoring des applications et état de santé • Finesse de configuration des affinités
    22. 22. #JSS2015 Les solutions logicielles • Network Load Balancing Windows Server • Load Balancing DNS en Round Robin • Solutions applicatives spécifiques (ex : ASLB)
    23. 23. #JSS2015 Scale Out avec Reporting Services
    24. 24. #JSS2015 • Seule la version Enterprise de Reporting Services prend en charge nativement le Scale Out du service de reporting : – Repository partagé (bases SQL ReportServer) – Mutualisation des objets, logs, cache, abonnements… • Le déploiement d’une répartition de charge sur des chaines SSRS indépendantes en version Standard pose des contraintes fortes – Opérations de déploiement et de maintenance – Mise en œuvre du cache, abonnements… Le Scale Out Reporting Services en mode natif
    25. 25. #JSS2015 Déploiement SSRS standard 25 • Le service de rapports et l’instance de base de données (catalogue SSRS) sont exécutés sur des serveurs différents • Configuration adaptée pour : – Charge de reporting modérée (utilisateurs concurrents) – Une volumétrie de données de reporting également modérée – Capacité de l’unique serveur de rapports à absorber la charge prévue
    26. 26. #JSS201526 Déploiement SSRS en Scale Out
    27. 27. #JSS201527 Déploiement SSRS standard en Scale Out • Fermes de frontaux SSRS en Scale Out • Bases Reporting Services sur serveur spécifiques • Partage des bases Report Server entre les nœuds • Ajout de serveurs par restauration de la clé SNK – Configuration du Host Name via le serveur virtuel – Configuration du View State Validation (processus unique de validation) https://technet.microsoft.com/en-us/library/cc281307(v=sql.110).aspx • Opérations unifiées sur la plateforme de reporting – Log, Déploiement, Cache, Abonnements • Possibilité de haute disponibilité sur le service SQL
    28. 28. #JSS201528 Déploiement SSRS en Scale Out et HA SQL
    29. 29. #JSS2015 Scale Out avec SharePoint BI
    30. 30. #JSS201530 Evolutivité de la ferme SharePoint 3 – Extension de la ferme en Scale Out avec ajout de frontaux web multiples adossés à une repartition de charge 1 – Déploiement sur serveur unique 2 – Bases SharePoint sur serveur SQL spécifique avec utilisation d’un alias sur le client SQL 30 4 – Séparation entre les couches frontales web et les couches applicatives SPS
    31. 31. #JSS2015 Ferme SharePoint 3 tiers Couche Web Couche Applicative Couche Données Répartition de charge (hors SPS) Frontaux Web SharePoint Serveurs Applicatifs SharePoint Serveur de bases de données Configuration et Contenu SPS Répartition de charge (interne SPS)
    32. 32. #JSS2015 Load Balancing des frontaux SharePoint 2013 • SharePoint repose sur une infrastructure Claims pour authentifier les utilisateurs au sein de la Ferme • Les jetons des logins utilisateurs sont désormais mis en cache dans le service de cache distribué (Distributed Cache Service) • Dans le cas d’un load balancing sur les WFE SharePoint, les utilisateurs s’authentifient une seule fois • Il n’est donc plus nécessaire de configurer une affinité au niveau de cet équilibrage de charge What's new in authentication for SharePoint 2013 https://technet.microsoft.com/en-us/library/jj219758.aspx
    33. 33. #JSS2015 Load Balancing Interne SharePoint SharePoint dispose nativement d’un mécanisme d’équilibrage des services d’application incluant les services BI suivants: - Excel Services - Reporting Services - PowerPivot Services, Performance Point…
    34. 34. #JSS2015 Load Balancing Excel Calculation Services Paramètre du Load Balancing ECS au niveau du service d’application. Les options de répartitions : - Workbook URL (defaut) : répartition via hachage de l’URL du book - Round Robin : rotation des serveurs applicatifs - Local : exécution locale sur le frontal web recevant la requête
    35. 35. #JSS201536 Ferme SharePoint 2013 Frontaux Web Clients Serveurs Applicatifs Bases SQL Server Base Config. Bases Contenu Base Service App SSAS en mode SharePoint (PowerPivot) Scale Out de PowerPivot pour SharePoint 2013
    36. 36. #JSS2015 Scale Out avec Analysis Services
    37. 37. #JSS2015 Les principes du Scale Out avec Analysis Services • 1 Instance de process • N Instances de requêtes en lecture seule • Différentes méthodes de transfert des données • Affinité de la session TCP-IP de l’utilisateur
    38. 38. #JSS2015 Synchronisation de base SSAS par XMLA • Natif depuis SQL Server AS 2005 • Synchronisation d’une instance cible en pointant une instance source • Scan et vérification des fichiers entre les deux instances, et transfert des fichiers modifiés • Imbrication des mécanismes de verrouillage et commit pour opérer la synchronisation • A envisager pour les faibles et moyennes volumétries
    39. 39. #JSS2015 Attachement et détachement des bases SSAS Attachement en lecture seule sur LUN partagé Serveurs de requêtes • Natif depuis SQL Server AS 2008 • Les serveurs de requêtes sont attachés en lecture seule sur un volume SAN partagé • Le dossier de la base SSAS doit au préalable avoir été détaché • Possibilité de spécifier un mot de passe lors du détachement
    40. 40. #JSS2015 Synchronisation des données par Switch de LUNS Scale-Out Querying for Analysis Services with Read-Only Databases https://technet.microsoft.com/en-us/library/ff795582(v=sql.100).aspx
    41. 41. #JSS2015 Le Robocopy avec Windows Server 2012 ROBOCOPY s’appuie sur le protocole « Server Message Block » (SMB) en version 3.0 lorsque la cible et la destination exécutent Windows Server 2012. Performance du ROBOCOPY avec Windows Server 2012 avec : - La capacité de ROBOCOPY à exécuter des copies en parallèle (threads multiples) - L’efficience du protocole SMB 3 - Possibilité d’activer le Multichannel http://blogs.technet.com/b/josebda/archive/2012/05/13/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0.aspx Get-SmbConnection PowerShell CmdLet pour vérifier la version SMB
    42. 42. #JSS2015 Exemple de mécanisme de synchronisation par Robocopy
    43. 43. #JSS2015 Scale Out avec SQL Server
    44. 44. #JSS2015 Utilisation des réplicats AlwaysOn en lecture seule 46Microsoft Confidential A A A A Mouvement asynchrone A A Réplicat primaire Réplicat secondaire Reports Sauvegardes Rapports Réplicat secondaire 3 Réplicat primaire Reports Réplicat secondaire 2 Réplicat secondaire 1 Mouvement synchrone
    45. 45. #JSS2015Microsoft Confidential Les groupes de disponibilité AlwaysOn Windows Server Failover Cluster Unité de haute disponibilité Réplicat géré au sein d’une instance SQL AG1 (DB1, DB2) AG1 (DB1, DB2) A Réplicat primaire A Réplicat secondaire
    46. 46. #JSS2015Microsoft Confidential La combinaison des réplicats Windows Server Failover Cluster AG1 AG1 AG1 AG1 AG1 …. A Réplicat primaire A Réplicat secondaire 1 A Réplicat secondaire 2 A Réplicat secondaire 8 A Réplicat secondaire 3 Mouvement synchrone Mouvement asynchrone
    47. 47. #JSS2015 • SQL Server Management Studio • Transact-SQL • PowerShell Configuration des réplicats en lecture seule
    48. 48. #JSS2015 Le Listener Constitue le point d’entrée à partir duquel les clients vont se connecter - Inclut : nom réseau, adresse IP et port - Definit les paramètres des ressources cluster - Nom réseau - Adresse IP
    49. 49. #JSS2015Microsoft Confidential Configuration du routage en lecture seule ALTER AVAILABILITY GROUP - Routing URL - URL et port écoutés par le réplicat lorsqu’il est “secondaire” - A configurer pour chaque réplicat accessible en lecture seule - Routing List - Liste des URLs de routing - A configure pour chaque réplicat - S’applique sur le replicat lorsqu’il est “primaire”
    50. 50. #JSS2015 Démo : Load Balancing des réplicats secondaires avec SQL Server 2016
    51. 51. #JSS2015#JSS2015 Les évaluations des sessions, c’est important !! http://GUSS.Pro/jss
    52. 52. #JSS2015 Merci à nos volontaires…
    53. 53. #JSS2015#JSS2015

    ×