[JSS2015] Infra bi#4 - le scale out
•
0 recomendaciones•726 vistas
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 !
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a [JSS2015] Infra bi#4 - le scale out
Similar a [JSS2015] Infra bi#4 - le scale out (20)
Más de GUSS
Más de GUSS (20)
[JSS2015] Infra bi#4 - le scale out
- 1. #JSS2015 Les journées SQL Server 2015 Un événement organisé par GUSS @GUSS_FRANCE
- 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. 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. #JSS2015 Merci à nos sponsors
- 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. #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
- 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. #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. #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. #JSS2015 Le principe du Scale Out
- 12. #JSS2015 Le principe du Scale Out Configuration “standard” Scale Up Scale Out
- 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. #JSS2015 La montée en charge avec le Scale Out
- 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. #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
- 18. #JSS2015 L’équilibrage de charge Scale Out Ferme de serveurs Nom DNS Accès utilisateur Répartiteur de charge
- 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. #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. #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. #JSS2015 Les solutions logicielles • Network Load Balancing Windows Server • Load Balancing DNS en Round Robin • Solutions applicatives spécifiques (ex : ASLB)
- 23. #JSS2015 Scale Out avec Reporting Services
- 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. #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. #JSS201526 Déploiement SSRS en Scale Out
- 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. #JSS201528 Déploiement SSRS en Scale Out et HA SQL
- 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. #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. #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. #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. #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. #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. #JSS2015 Scale Out avec Analysis Services
- 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. #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. #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. #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. #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. #JSS2015 Exemple de mécanisme de synchronisation par Robocopy
- 43. #JSS2015 Scale Out avec SQL Server
- 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. #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. #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. #JSS2015 • SQL Server Management Studio • Transact-SQL • PowerShell Configuration des réplicats en lecture seule
- 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. #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. #JSS2015 Démo : Load Balancing des réplicats secondaires avec SQL Server 2016
- 51. #JSS2015#JSS2015 Les évaluations des sessions, c’est important !! http://GUSS.Pro/jss
- 52. #JSS2015 Merci à nos volontaires…
- 53. #JSS2015#JSS2015
Notas del editor
- 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 !