SQL Server équivalent aux fonctionnalités d'Oracle RAC? [fermé]

11

J'ai fait quelques recherches sur Google et je n'ai pas trouvé de réponse à cette question plus récente qu'il y a quelques années, alors j'ai pensé que je poserais la question. La fonction Oracle RAC offre un équilibrage de charge pour les transactions en lecture et en écriture, ainsi que la mise à l'échelle et la haute disponibilité sans temps d'arrêt (du moins, si je comprends bien - nous sommes sur le point de déployer nos premières bases de données qui utilisent RAC, donc nous Je vais voir comment ça se passe).

Existe-t-il un ensemble de fonctionnalités SQL Server (ou un composant tiers que vous pourriez installer par-dessus) qui offre des fonctionnalités équivalentes? Nous avons toujours utilisé le clustering Windows, où un événement de basculement provoque environ 20-30 secondes de temps d'arrêt SQL - toujours tolérable, mais pas idéal. Maintenant, avec AlwaysOn dans SQL 2012, SQL Server réduit cela à environ 15 secondes et ajoute le concept de bases de données secondaires en lecture seule, mais ils nécessitent toujours que les transactions d'écriture soient étouffées via un seul point de connexion (beaucoup amélioré, car de nombreuses transactions sont il suffit de lire, mais toujours pas vraiment d'équilibrage de charge), et en cas de défaillance d'un nœud ou de nécessité de patcher, il y a toujours un temps d'arrêt.

Je suppose que c'est juste plus de curiosité - j'ai l'impression que c'est le seul domaine dans lequel SQL Server se situe derrière Oracle (au moins parmi les fonctionnalités que j'ai personnellement vues utilisées). Je voulais voir s'il existe des options pour combler cet écart et éventuellement améliorer notre propre déploiement SQL Server pendant que nous attendons que la fonctionnalité équivalente de Microsoft soit ajoutée - peut-être dans SQL 2014/2015?

sql-server feature-comparison high-availability rac oracle-rac SqlRyan
la source
1
Je ne suis pas sûr que SQL Server soit vraiment aussi loin derrière Oracle. Eh bien, oui, il a une fonctionnalité que SQL Server n'a pas, mais assurez-vous de revoir ce fil après l'avoir exécuté pendant quelques mois et de nous faire savoir si tout est rose ou non. :-) Je n'ai pas d'expérience non plus mais des collègues qui n'ont pas toujours eu de belles choses à dire à ce sujet.
Aaron Bertrand
2
J'espère également que vous ne vous attendez à aucune spéculation précise sur les fonctionnalités des futures versions de SQL Server. Ceux qui savent s'il existe ou non de telles fonctionnalités dans la phase de planification ne peuvent pas vous le dire; ceux qui ne le savent pas non plus. :-)
Aaron Bertrand
1
@AaronBertrand: Très bien, je ne m'attends pas vraiment à des spéculations sur les fonctionnalités, car je me rends compte que ce ne serait pas du tout exact. Bien que AlwaysOn soit une amélioration (dans certains cas), j'avais plus d'espoir qu'il reproduirait plus étroitement les fonctionnalités de RAC et comblerait cet écart. MSSQL fait un certain nombre de choses mieux qu'Oracle, à mon avis, mais c'est un domaine où Oracle détient le relais, à mon avis.
SqlRyan
1
@rwmnau encore une fois, je vous suggère de garder votre éloge élogieux de RAC jusqu'à ce que vous l'ayez mis en œuvre et l'utilisiez depuis quelques mois. :-) Il se peut que vous ayez raison; il pourrait être tout ce qu'il promet et fonctionnerait parfaitement pour vous. Mais vous pourriez être embobiné par les paillettes brillantes sur la boîte. :-)
Aaron Bertrand
2
@AaronBertrand: Ha, point pris. J'ai entendu un certain nombre de critiques, comme le fait qu'il est trop sensible à la latence du réseau et qu'il est rapide d'expulser les nœuds et autres, donc je garde définitivement un jugement total jusqu'à ce que nous l'ayons déployé et que je l'utilise de première main . SQL Server, bien qu'il ait un certain nombre d'options HA, ne semble pas se déplacer dans l'espace "front end inscriptible multiple". Je suis peut-être sur le point de découvrir la raison pour laquelle :)
SqlRyan

Réponses:

8

Non, rien dans SQL Server ne peut vous offrir la même chose hors de la boîte .

Actuellement, la seule technologie SQL Server qui permet des écritures simultanées sur plusieurs nœuds est la réplication d'égal à égal . Notez que je n'ai pas dit «écriture évolutive», car cela fonctionne d'une manière telle que l'ensemble du système n'a la capacité d'écriture que d'un seul nœud. Le paragraphe introductif de cette page est rédigé avec soin pour inclure le terme «scale-out» sans dire «écrire scale-out». Ouais pour parler marketing.

D'après ce que j'ai lu , Oracle RAC est le même à cet égard. Fonctionnellement, la seule chose qui manque à SQL Server dans cette configuration est une solution d'équilibrage de charge, qui est à la fois un avantage (vous pouvez l'implémenter comme vous le souhaitez) et un inconvénient (ce n'est pas dans la boîte ou pris en charge par Microsoft) lorsque comparer avec des produits concurrents.

A l' inverse, Oracle RAC ne vous donne pas la même chose que SQL Server de la boîte soit. Par exemple, il est recommandé d'implémenter RAC avec des nœuds à moins de 100 km les uns des autres en raison de la latence du réseau en temps réel, tandis que la réplication d'égal à égal n'a pas une telle restriction. (Je ne dis pas qu'une solution est meilleure que l'autre: je souligne simplement qu'elles sont différentes. L'entreprise doit choisir une solution qui correspond le mieux à ses besoins spécifiques.)

Jon Seigel
la source
1
La raison principale de la distance de 100 km est parce qu'Oracle reste conforme à ACID sur tous les nœuds - ils doivent communiquer entre eux via une interconnexion à grande vitesse et la vitesse de la lumière devient un problème. SQL Server dans une configuration similaire propage les modifications et vous pouvez obtenir des conflits au niveau des lignes si deux nœuds mettent à jour la même ligne dans un certain laps de temps - pas ACID - pas une seule base de données. Un ensemble d'instances RAC est une base de données unique, c'est la distinction.
Philᵀᴹ
@Phil: Oui, c'était mon point - ils sont différents.
Jon Seigel
6

Je suis un DBA prenant en charge SQL 2000-2012, Oracle 11g et Oracle 11g RAC.

IMO, Always On Availability Groups dans SQL 2012 est très proche de la disponibilité et de l'évolutivité de RAC à un coût beaucoup moins élevé en dollars et en complexité. Vous pouvez étendre les lectures en interrogeant les miroirs, mais vous souhaitez diriger tous les DML vers le serveur principal (les miroirs SQL Server ne peuvent pas être mis à jour). Si le serveur SQL Server principal se bloque, le basculement vers l'un des miroirs est presque instantané. RAC connaît une pause similaire si un nœud se bloque lorsque les transactions non validées sur le nœud défaillant sont annulées par le nœud survivant.

Le plus grand avantage (IMHO) de SQL 2012 AAAG par rapport à RAC est qu'il s'agit d'une architecture de partage rien. RAC partage le stockage. Si cela échoue, l'ensemble du cluster est arrêté. C'est un énorme SPOF dans RAC que tout le monde semble oublier. Si vous souhaitez vous protéger contre cela, vous devez configurer un serveur de secours. Si vous voulez que ce soit RAC, le coût est encore plus élevé.

Mandrin
la source
1
Bon point sur le SPOF de RAC.
StanleyJohns
1

Une meilleure comparaison de AlwaysOn serait la fonction Data Guard d'Oracle. Clustering actif-passif. (oui, vous pouvez lire en mode veille, mais il est en lecture seule, donc un seul nœud est toujours actif ")

Oracle RAC est un animal complètement différent et un clustering actif-actif. Je n'ai vu aucun mouvement si Microsoft voulait un jour l'implémenter.

Tagar
la source
-2

SQL Server 2012/2014 avec AlwaysOn ajoute de nombreuses fonctionnalités qui vous rapprochent d'Oracle RAC et, dans certains cas, l'améliorent. (Rappelez-vous qu'avec RAC, vous devez utiliser Oracle app server, weblogic et JDBC - en plus de fonctionner dans un seul centre de données et l'application ne peut se connecter qu'à un seul cluster RAC - le stockage partagé signifie que RAC ne fonctionne pas dans le cloud) .

Avec AlwaysOn, vous obtenez des secondaires en lecture seule (4 sur 12, 8 sur 14) et une prise en charge du basculement automatique. Cependant, certaines choses sont difficiles - AlwaysOn ne prend pas en charge l'équilibrage de charge - à moins que vous n'écriviez un script, il attirera toujours le premier serveur de la liste. Le basculement a également un impact sur l'application - il n'est pas transparent, il peut donc être nécessaire de redémarrer les applications.

Divulgation complète - Je travaille pour une entreprise qui fabrique des logiciels qui augmentent AlwaysOn. Notre logiciel d'équilibrage de charge de base de données frontale SQL Server - il effectue une répartition en lecture / écriture au nom de l'application, un équilibrage de charge basé sur le temps de réponse qui s'étend sur les centres de données et met en file d'attente les écritures / transactions entrantes pendant le basculement afin que les applications ne voient pas les erreurs . Découvrez comment Microsoft, Dell, Quicken Loans et d' autres entreprises utilisent le logiciel ScaleArc pour augmenter SQL Server AlwaysOn et obtenir des fonctionnalités de type RAC sans modification d'application.

Michelle
la source