Accueil Bases de données Protégez votre base de données: haute disponibilité pour les données à forte demande

Protégez votre base de données: haute disponibilité pour les données à forte demande

Anonim

Par Techopedia Staff, 7 décembre 2016

À retenir: l' animateur Eric Kavanagh discute de la disponibilité avec Robin Bloor, Dez Blanchfield et Bert Scalzo d'IDERA.

Vous n'êtes actuellement pas connecté. Veuillez vous connecter ou vous inscrire pour voir la vidéo.

Eric Kavanagh: Mesdames et messieurs, bonjour et bienvenue encore une fois. Il est 16 heures, heure de l'Est un mercredi, et ces jours-ci, cela peut signifier à peu près une chose si vous êtes dans le monde des données: il est de nouveau temps pour Hot Technologies! Oui en effet.

Je m'appelle Eric Kavanagh, je serai votre hôte pour le spectacle. Il est conçu pour comprendre ce qui est chaud, ce qui se passe là-bas, ce qui est cool qui est utilisé dans l'entreprise, et bien sûr, la base de données est à la base de tout ce que nous faisons dans ce domaine. Nous allons donc parler de la protection de votre base de données. Le sujet exact est «Protégez votre base de données: haute disponibilité pour les données à forte demande». Donc, il y a vraiment une diapositive sur la vôtre. Et, assez parlé de moi, contactez-moi sur Twitter, @eric_kavanagh.

Premièrement, cette année est chaude, les données sont chaudes, les mégadonnées sont très chaudes, mais c'est vraiment encore un peu à la limite. De plus en plus d'entreprises de pointe exploitent les mégadonnées ces jours-ci, la plupart des organisations de pain et de beurre dans le monde, elles utilisent toujours des données traditionnelles, et si vos données sont en forte demande, vous voulez vous assurer qu'elles sont disponibles car lorsque les systèmes tombent en panne, lorsque les données sont inaccessibles, c'est à ce moment-là que vous obtenez des clients mécontents, des prospects mécontents, vous obtenez un taux de désabonnement des clients, vous êtes mécontents de toutes sortes de choses, de partenaires, etc. Vous ne voulez donc pas cela.

Nous allons apprendre des meilleurs aujourd'hui de l'industrie - nous entendrons notre propre Dr Robin Bloor, expert en bases de données depuis environ trois décennies. Dez Blanchfield, qui fait cela depuis aussi longtemps, mais il a commencé quand il était très jeune, et Bert Scalzo de IDERA, qui est vraiment la ceinture noire de la base de données. Alors ne vous retenez pas, les gens, posez des questions - la grande partie de cet événement est précieuse pour vous lorsque vous posez de bonnes questions et obtenez de bonnes réponses, alors envoyez-les via la fenêtre de discussion ou le composant Q et A de votre console.

Et avec cela, je vais le remettre à Robin Bloor - le retirer.

Dr Robin Bloor: D' accord, laissez-moi cliquer dessus et voir si ça bouge - ça marche. Je ne vais pas parler de base de données en particulier. Je pensais que, vous savez, parce que je fais l'intro, la première présentation, je vais donc parler des niveaux de service attendus et bien sûr de la disponibilité, ce qui est l'affaire, qui est le sujet de l'émission d'aujourd'hui.

Et la question est de savoir: «Vraiment, quelle est la disponibilité? Et quel rôle cela joue-t-il dans la façon dont les gens gèrent les centres de données de nos jours? »Une chose que j'ai remarquée - je l'ai remarqué en fait dans les années 90 - je travaillais sur un site et les utilisateurs ont commencé à se plaindre parce que leur e-mail était en panne depuis 15 minutes.

Et c'était intéressant parce que le CTO ou celui qui était en charge de l'informatique avait en fait, l'un des rares endroits où, à l'époque, ils avaient effectivement déterminé les niveaux de service et que le courrier électronique étant en panne pendant 15 minutes ne violait le niveau de service de personne. . Je pense qu'il est autorisé à être absent pendant deux heures, en fait. Ce n'était pas l'e-mail qui ne pouvait pas être utilisé, c'était juste que vous ne pouviez pas envoyer et recevoir parce que le serveur était hors service. Et ce genre de m'a alerté sur le fait que j'ai remarqué aller de l'avant depuis lors, que tout s'accélère tout comme les attentes des utilisateurs, et cela vous amène à la situation où les gens peuvent avoir trois niveaux de service, mais souvent ils commencera à se plaindre lorsque les niveaux de service ne sont pas réellement violés.

Donc, la définition des niveaux de service, juste pour donner un - eh bien, cela peut dépendre exactement de ce dont vous parlez en termes de niveaux de service. Nous avons parlé de système informatique ou d'application informatique. Normalement, définissez en termes de performances, de disponibilité et de métriques - en d'autres termes, vous ne pouvez pas vraiment définir un niveau de service à moins de pouvoir le mesurer, donc normalement il y a une sorte de mesure impliquée et il s'agit normalement des temps de réponse, des transactions particulières et de la disponibilité des systèmes sur une période de temps donnée, et avant 1994-1995 environ, il était vraiment rare que des systèmes devaient être disponibles pendant plus que la durée normale du travail. Alors disons huit heures du matin jusqu'à six heures du soir, pour donner une durée normale - et les gens ont construit des systèmes et ainsi et cela signifiait - dans mon esprit, en particulier avec la base de données - vous pourriez configurer la base de données d'une manière particulière et comme la fenêtre de traitement par lots a commencé à rétrécir, la nécessité de réfléchir à nouveau a commencé à apparaître dans certains systèmes, puis dans d'autres systèmes, puis nous avons eu l'avènement du service ou de l'architecture, qui a commencé à faire des dépendances entre des systèmes qui ne dépendaient pas auparavant les uns les autres, ce qui aggrave encore tout. Nous avons eu la pression en termes de disponibilité des systèmes.

Ce que je voulais dire, c'était quand on parlait de disponibilité, cela inclut la sauvegarde et la récupération et inclut - ce n'est pas seulement la disponibilité dans les termes normaux dont nous parlons; il existe de nombreuses manières différentes de faire échouer une application. Vous savez, vous pouvez obtenir une défaillance matérielle ou vous pouvez obtenir la défaillance de la base de données, vous pouvez obtenir une défaillance logicielle et il existe de nombreuses espèces différentes de ces choses, et quand cela se produit, vous devez pouvoir récupérer et donc vous devez également sauvegarder les systèmes. Il doit donc y avoir un plan de sauvegarde du système et vous aussi, sur de nombreux sites de nos jours, vous avez besoin de la capacité de reprise après sinistre au cas où un bâtiment entier exploserait. Et quelque chose qui mérite d'être mentionné ici, et je vais en parler dans une minute, mais les processus métier, ils ont aussi des niveaux de service, et en fait, les niveaux de service du processus métier qui comptent vraiment pour l'entreprise. L'informatique n'a qu'à faire sa part et selon n'importe quel accord.

Les niveaux de service informatique sont normalement subsidiaires aux niveaux de service des processus métier, mais comme il était très rare il y a 15 ans pour une organisation d'avoir des niveaux de service bien définis, il est encore assez rare pour les organisations d'avoir des niveaux de service bien définis pour les processus métier. . C'est quelque chose qui se produit actuellement; ce n'est pas quelque chose qui dure depuis longtemps.

Ce sont les barrières d'accélération et de temps, il convient de mentionner les barrières de temps. Nous entrons progressivement dans un monde de traitement d'événements et, à cause de cela, nous entrons progressivement dans un monde en temps réel, et à cause de cela, nous passons progressivement à la disponibilité pour être requis 24 heures sur 24, 7 jours sur 7, et c'est en fait difficile pour beaucoup de systèmes - c'est difficile à réaliser. Soit c'est très cher, soit dans certains cas, vous devrez peut-être changer les systèmes, voire passer à une autre base de données, une version différente du logiciel de base de données que nous utilisons.

De plus, ces barrières temporelles - et j'aime toujours les mentionner chaque fois que j'en ai l'occasion - ce sont des barrières temporelles dans lesquelles nos applications se heurtent; les applications peuvent vouloir être aussi rapides que possible, c'est à ce moment que le logiciel parle au logiciel. Il n'y a vraiment pas de licence acceptable dans certaines situations, vous voulez être aussi rapide que possible, et ces situations dans les conditions commerciales comme les situations de marché, où la personne qui vient avec le deuxième ordre d'achat obtient un prix pire que quelqu'un qui vient en premier, et donc la vitesse du logiciel compte vraiment.

Mais vous savez, en dessous de cela lorsque vous avez réellement affaire à - interagissant avec - des êtres humains, le meilleur temps de réponse qui peut vraiment être exigé de vous est un dixième de seconde, car il s'agit du temps de réponse d'un être humain. Vous n'avez pas besoin d'aller plus vite que cela parce qu'un être humain ne le remarquera pas de toute façon. Entre 1, 1 et quatre secondes est un temps d'attente que les êtres humains tolèrent normalement, mais dès que vous dépassez environ quatre secondes, ils sont en train de faire autre chose, et donc vous êtes vraiment dans une activité par lots.

Ainsi, vous pouvez voir que certains délais et jours, semaines et mois pour les choses où un comportement par lots a du sens et donc vous n'êtes pas dans un monde de traitement d'événements, et donc la disponibilité peut être en fait très différente en termes de ce dont vous avez besoin être en mesure de fournir. Mais dès que vous êtes dans le monde des événements, alors vous êtes dans une certaine disponibilité 24/7 et le changement technologique est un facteur car la technologie va de plus en plus vite, alors la disponibilité peut ne pas augmenter; il reste tel quel.

Ce sont des couches de complexité et je ne veux pas entrer dans les détails, c'est juste, vous savez, qu'il y a trois choses à considérer ici. Il y a le niveau de service de l'infrastructure, c'est l'axe vertical, puis il y a le niveau de service de n'importe quelle application donnée et ensuite il y a un niveau de service commercial, et ceux-ci dépendent les uns des autres et ils devront être pris en considération si vous cherchez à créer un environnement réactif où les niveaux de service sont atteints, en gros.

Ensuite, vous avez, en bas ici, qui ne sont que des bases de données représentées, mais vous pouvez faire n'importe quoi dans le système, vous savez que vous avez la configuration sans arrêt, ce qui signifie ce qu'elle dit: elle ne s'arrêtera jamais. Vous avez la situation de redondance d'UC, où d'une manière ou d'une autre, il existe différentes façons d'y parvenir, mais d'une manière ou d'une autre, si une base de données échoue, elle passe en redondance d'UC et il y a très peu de décalage en termes de temps, au point où les utilisateurs remarqueraient probablement, mais ne remarqueraient pas grand-chose.

La mise en veille chaude ressemble plus au basculement de 20 minutes où tout le monde appelle le service d'assistance et les chiennes au service d'assistance pendant que la base de données est basculée en veille. Ensuite, il y a une situation de redémarrage où cela peut prendre une très longue période de temps. Il convient de noter qu'une application donnée ou une base de données donnée peut se trouver dans l'une des situations en fonction de ce qui se passe réellement et du niveau de service requis pour l'application.

De cela, je veux juste faire un point sur la courbe de complexité. La complexité dérive des nœuds et des connexions, des dépendances. Dans le monde dans lequel nous vivons, le nombre de nœuds et de connexions impliqués dans quoi que ce soit ne cesse de croître, alors vous vous dirigez vers ce type de courbe expérientielle. Si vous pouvez voir comment la complexité augmente et la façon dont les dimensions temporelles diminuent, alors vous savez pour les niveaux de disponibilité, y a-t-il des objectifs de temps, sont-ils susceptibles de réduire?

Et l'évolution naturelle est donc vers un fonctionnement sans arrêt, qui est bien sûr le plus cher - du moins d'après mon expérience - ce sont les configurations les plus chères que vous pouvez créer. D'une manière ou d'une autre, toute organisation qui pense à cela doit vraiment penser non seulement à ce qui se passe maintenant, mais à ce qui va se passer à l'avenir.

Le dernier point que je veux faire valoir est peut-être que la gestion des niveaux de service est une activité continue; ce n'est pas quelque chose que vous savez que vous avez un projet, vous le faites et c'est fini. Ce n'est pas le cas, car les choses ne cessent de changer. Cela dit, je passe le ballon à Dez.

Dez Blanchfield: Merci Robin. J'adore ta diapositive d'ouverture. Nous venons juste de reprendre, je pense que c'est "Finding Nemo 2", le film. Vous avez eu Nemo à la recherche de disponibilité sous forme de neuf, ce qui m'a semblé assez mignon. Toujours un acte difficile à suivre. Quand je pense à la disponibilité et à la disponibilité et aux hautes performances, la première image qui me vient à l'esprit, parce que j'ai grandi aux Îles Salomon près des volcans et de l'équateur, est un volcan en éruption dans mon centre de données; il y a cette image que j'ai toujours dans mon esprit que c'est ce qui pourrait potentiellement arriver si quelque chose se produisait. C'est une photo du charmant mont. Etna, qui est le coin nord-est de la Sicile, qui est juste à côté de Catane.

Mon approche consiste à avoir une conversation avec vous et à vous donner quelques plats à emporter au même niveau que je fais dans une salle de réunion sur une base régulière de C-suites et les chefs de métier en vue que nous avons une conversation sur ce qui peut affecter votre organisation d'un point de vue commercial ou technique et les types d'ingénierie.

Nous devons réfléchir et comment - ce que nous en retirons, et comment nous allons aborder ensuite certains des défis dont nous parlons lorsque nous parlons de haute disponibilité et de disponibilité, en particulier autour de l'automatisation et des plates-formes.

Donc, la question que nous posons initialement est, que voulons-nous dire réellement lorsque nous parlons des systèmes de base de données et de la disponibilité de la plateforme de base de données? Qu'est-ce que cela signifie réellement de parler du défi réel de rendre quelque chose disponible à un niveau comme Robin l'a mentionné dans l'accord de niveau de service installé, cartographie de ce dont nous avons réellement besoin et que nous voulons?

Donc, la réalité d'aujourd'hui est que - et en fait voici quelques réalités de pointe dans mon esprit - aujourd'hui tout est effectivement piloté par une base de données. Il y a très peu de systèmes qui sont construits aujourd'hui et construits de telle manière que les choses soient simplement stockées dans des fichiers ou soient une sorte de journal de fichiers plat; invariablement, tout est piloté par une base de données. En conséquence, nous avons besoin d'arrêter de penser à la disponibilité de ces bases de données, des différents systèmes et applications et outils qui en dépendent et de compter sur eux pour fournir les services que nous cherchons à fournir, vendre ou consommer. . Et toutes les infrastructures qui l'entourent.

En fait, si bien que vous pensez aux grandes perturbations des données ces derniers temps, en particulier les natifs numériques ou natifs du cloud, certaines des entreprises qui se sont succédé comme Uber et Airbnb et ainsi de suite, et les PayPals légèrement plus anciens et les eBays du monde - l'échelle et la taille de ces organisations ne sont possibles qu'en raison de la technologie de base de données moderne et de l'infrastructure cloud moderne. Sans cela, sans la capacité supplémentaire fournie, ils n'existeraient certainement pas. Imaginez un scénario où vous ne pourriez accéder à eBay qu'entre 9h05 et 9h25 car il n'était pas disponible pour le reste de la journée car il essayait de faire un iCloud ou une sauvegarde ou quelque chose comme ça, il n'aurait tout simplement pas travaillé.

Donc, et il y a d'autres domaines clés quand vous pensez à notre vie de tous les jours, vous savez, comme le commerce de détail et la banque et la finance et les compagnies aériennes et ainsi de suite. Les grands groupes industriels comme la logistique de l'aviation, le transport maritime, il y a le gouvernement dans son ensemble, il y a la sécurité nationale et la police et ainsi de suite. Toutes ces industries, tous ces segments de marché, tous ces organismes, tous ces groupes dépendent de la mise en service de leur environnement.

Donc, avec cela à l'esprit, nous avons également l'autre mise en garde à laquelle nous devons penser, l'autre point à retenir auquel je veux vous laisser penser, et c'est que notre monde est maintenant ce que j'appelle «toujours actif». Nous sommes connectés en permanence et c'est un thème que vous entendrez régulièrement et je vais le répéter et le répéter. Nous avons maintenant des smartphones entre nos mains toute la journée, tous les jours. Nous ne les éteignons pas, nous les mettons à côté du lit, nous les utilisons invariablement comme réveils, nous les utilisons comme caméras et nous prenons des photos, ils poussent ces photos dans le nuage.

Ils sont toujours actifs, mentalité connectée en permanence. En fait, il y a une pièce d'expression que j'aime utiliser, et c'est que nous vivons maintenant en quelque sorte la génération Fitbit, où nous mesurons tout, nous surveillons tout, et elle doit être enregistrée et ça va aller quelque part.

Et il y a aussi une autre phrase que je vais vous laisser, c'est qu'il est neuf heures quelque part, tout le temps. C'est un monde 24/7/365 dans lequel nous vivons. La Terre tourne constamment autour du Soleil et à un moment et à une heure différents, il est neuf heures du jour. Et cela signifie que les gens sortent du lit et essaient de faire des choses, d'acheter des choses, d'installer des choses, etc.

Alors, que voulons-nous dire lorsque nous parlons de haute disponibilité? Eh bien, cela semble vraiment évident jusqu'à ce que vous commenciez à plonger dans les détails. Donc, vous savez quand nous pensons à «OK, qu'est-ce que la haute disponibilité signifie?» Eh bien la réalité est, il n'y a pas de solution miracle. C'est un concept assez complexe, comme Robin l'a lié à certains des sujets qu'il a mentionnés, tels que la mesure de la disponibilité et des accords de niveau de service. Nous l'associons à des choses comme, j'ai ces questions, est-ce la disponibilité? Nous inquiétons-nous de choses comme ce que nous appelons cinq neuf, dans lesquelles j'entrerai dans une minute. Nous considérons-nous avec ce qui est dans nos accords de niveau de service? Par exemple, dans les accords de niveau de service, je veux dire qu'il y a des retards, l'acronyme à trois lettres pour les accords de niveau de service est devenu de plus en plus critique de nos jours.

Au fur et à mesure que vous passez par tout ce processus de sur site et auto-hébergé vers des centres de données tiers et des services gérés externalisés, nous allons maintenant jusqu'au cloud. Et la réalité est que lorsque vous parlez de cloud, ce sont vraiment les ordinateurs des autres. Et cela signifie que vous n'exécutez pas l'infrastructure, que vous n'exécutez pas les systèmes et que vous n'exécutez pas toujours le cloud. Vous faites l'infrastructure configurée comme plate-forme, c'est donc encore plus important dans le service de la force de vente. Imaginez maintenant les ventes par exemple, vous savez que vous ne touchez à aucune de ces infrastructures, vous vous connectez simplement à une interface Web.

Donc, le seul mécanisme que vous avez dans ce monde de cloud et d'infrastructure externalisée de toute forme pour contrôler qui est les accords de niveau de service, c'est le seul mécanisme que vous avez, et si les gens ne rencontrent pas votre installation, alors ils perdurent des pénalités et une réduction du montant que vous leur versez ou que vous ne payez tout simplement pas.

Donc, cela ramène à l'esprit tout ce défi de savoir comment gérer la haute disponibilité? Comment gérer la disponibilité de la disponibilité si ce n'est pas votre infrastructure - tout dépend du SLA, par exemple. Si c'est votre infrastructure ou même si c'est l'infrastructure de quelqu'un d'autre comme point de vue de conception. Nous avons parlé de l'équilibrage de charge à la science du modèle, est-ce un brevet de conception de tolérance aux pannes?

Exécutez-vous Active Active ou Active Standby dans vos architectures? Avez-vous plusieurs serveurs, plusieurs plates-formes de stockage? Comment fonctionnent ces plateformes de stockage? Se reproduisent-ils, se reflètent-ils? Utilisez-vous RAID? Quel type de RAID utilisez-vous pour le stockage redondant? Exécutez-vous un RAID au niveau du disque? Exécutez-vous une plate-forme de stockage d'objets qui se réplique sur les lecteurs modèles et les systèmes et lecteurs modèles? Est-ce N plus un pour chaque petit morceau d'infrastructure que vous avez? En ajoutez-vous un autre et est-ce dans le même centre de données ou dans un autre centre de données? Avez-vous construit un brevet de conception qui ne représente pas un seul point de vente, par exemple?

Toutes ces choses fondamentales, maintenant elles sonnent comme des concepts simples, mais quand vous entrez dans chacune de ces choses, ce sont des choses très, très détaillées. Lorsque nous parlons de disponibilité, nous finissons invariablement par parler de neuf. Et que voulons-nous dire par neuf? Nous en avons tous entendu parler, mais réfléchissons un instant à leur signification et à leur importance.

Donc, nous parlons d'un neuf, ce qui ne représente que 90% de notre disponibilité. Je sais que cela semble très élevé. Ainsi, lorsque nous parlons 24 heures sur 24, 7 heures sur 365, si nous considérons un an par exemple, lorsque nous parlons à neuf heures, ce qui représente 90% du temps, cela permet trente-six jours et demi de temps d'arrêt par an. Disons simplement arrondir cela à un peu plus d'un mois.

Pensez maintenant à toute entreprise avec laquelle nous traitons tous les jours - que ce soit les services bancaires en ligne, eBay, PayPal ou les plateformes de médias sociaux comme LinkedIn, Twitter ou tout simplement un détaillant général - disons simplement que je voulais réserver un vol pour venir aux États-Unis sous le soleil Australie, serais-je heureux si je voulais venir en Amérique dans une semaine, si ma compagnie aérienne préférée était en panne pendant trente-six jours et demi parce que leur fournisseur de services a dit: «Écoutez, nous sommes prêts pour 90% du temps "? Bien sûr que non.

Au fur et à mesure que vous montez ce modèle, deux neuf: 99 pour cent. Eh bien, cela devient 3, 65 jours, soit environ trois jours et demi d'indisponibilité par an. Est-ce une grosse affaire? Eh bien, c'est le cas si vous exécutez le Black Friday et que vous organisez une vente spéciale et que les gens ne peuvent acheter que pendant ces quelques jours.

Trois neuf deviennent aussi peu que 8, 7 heures par an, mais même 8, 7 heures par an, ce sont huit heures consécutives non-stop de notre temps. Eh bien cela dans les banques et la finance, dans la santé - si c'est un hôpital, ça pourrait coûter des vies. Lorsque vous montez, quatre neuf correspondent à 52 minutes, cinq à cinq minutes et six à 30 secondes. Six neuf est extrêmement élevé, et lorsque vous montez cette échelle, que vous montez sur cet arbre de Noël de neuf, plus vous montez de neuf, plus la conception, l'environnement et la plate-forme sont difficiles. Plus il est difficile de fournir ce service, et si vous pensez à la réduction du temps dont vous disposez pour exécuter des sauvegardes, l'administration, les correctifs, les fenêtres de maintenance pour toute forme de panne - tous les défis non triviaux - et tout se résume à des pourcentages de pannes, effectivement.

La clé ici que je voudrais transmettre est qu'il n'y a pas de solution miracle, comme je l'ai mentionné précédemment. En ce qui concerne la disponibilité, il n'y a pas de «solution unique». Vous pouvez avoir un type particulier de brevet de conception qui convient aux industries clés. Les mêmes défis sont rencontrés par toutes les banques. Certains pourraient être des banques de détail, certains pourraient être des banques premium. Certaines banques pourraient se concentrer sur le commerce et l'investissement, la gestion de patrimoine. Certains pourraient être purement consommateurs. Certains peuvent utiliser Internet uniquement et même ne pas avoir de guichets et ne traiter que les distributeurs automatiques de billets lors de la distribution d'espèces. Donc, dans ces scénarios, même dans le secteur bancaire et de la gestion de patrimoine et des services financiers dans leur ensemble, pour chacun d'eux, ils ont toujours leur propre saveur ou ce dont ils ont besoin en matière de disponibilité.

Donc, quand nous pensons à la disponibilité en anglais simple, le mélange entre disponibilité et haute disponibilité - nous pensons que c'est la même chose, mais ce sont en fait de la craie et du fromage. La disponibilité est, je l'ai mis dans un anglais simple, une mesure du temps qu'un serveur ou un processus fonctionne normalement ou généralement, lié à leur utilisation. Cela signifie simplement comment nous décrivons s'il est disponible ou non. Lorsque nous parlons de disponibilité, nous tombons souvent dans ce piège de la pensée: «Je le fournis sous une forme disponible», par opposition à la haute disponibilité pour protéger la sécurité de cette infrastructure.

La haute disponibilité, dans un autre sens en anglais simple, est la conception où vous implémentez ou atteignez une sorte de résultat et de disponibilité des données, en particulier lorsque presque tout le temps - 24/7/365 jours par an - cette disponibilité arrive à certains d'entre eux neuf. Invariablement, cela ne signifie pas 100%. Cent pour cent n'est techniquement pas possible dans un monde réel dans un environnement donné. Il est très difficile pour un serveur dans un système d'exploitation avec une base de données, une plate-forme en cours d'exécution et sur laquelle une application, vous pouvez la livrer et vous attendre à ce qu'elle fonctionne à 100%. Alors nous commençons à penser aux designs. Avons-nous des redondances, avons-nous plusieurs diapositives à répliquer? Ensuite, lorsque vous le mettez dans un anglais simple, il est intéressant de voir à quel point le sujet de la disponibilité est différent de la haute disponibilité.

J'ai pensé que je le mettrais sous une forme graphique très simple juste pour nous donner une idée de ce à quoi cela ressemble lorsque vous commencez à relever le défi d'augmenter la disponibilité en protégeant la disponibilité de votre service. Dans le coin inférieur gauche, nous avons un seul neuf. J'ai énoncé les cinq neuf dont nous parlons généralement. Six neuf est un peu scandaleux. Lorsque nous parlons de cinq neuf dans le coin inférieur gauche, soit environ 35 jours de cette panne, c'est un environnement à faible coût et à faible complexité que vous essayez de fournir car vous avez un certain nombre de choses qui peuvent échouer et vous pouvez respectez toujours vos accords de niveau de service.

Mais en parcourant le bas de gauche à droite et en arrivant au point où il y a plus de neuf dans l'image, vous obtenez les scénarios où vous commencez à penser à la réplication des systèmes et des plates-formes. Il faut penser au clustering et à la virtualisation de différentes parties de l'infrastructure. Vous devez penser à la géolocalisation de ces clusters, de plusieurs sites de centres de données, et vous devez penser au type d'industrie et de segment de marché que vous visez. Alors, quel type de niveau de service devez-vous atteindre? Quelle prestation de services recherchez-vous? Les zones qui sont des services basés sur des cartes en temps réel qui parlent des communications. S'agit-il de services militaires? Ce graphique va donc du bas à gauche au haut à droite et à mesure que vous parcourez cette courbe, le coût et la complexité augmentent. À mesure que vous obtenez des environnements plus complexes et plus exigeants, vous allez avoir besoin de plus de neuf.

Ce graphique, par exemple, fait une chose très similaire: il décrit l'histoire entre la composante de coût et la composante de disponibilité souhaitée. Ainsi, dans le coin supérieur gauche, nous mappons les systèmes complexes hautement disponibles et le coût encouru si cette disponibilité diminue par rapport à l'avantage d'avoir une disponibilité sans temps d'arrêt. Ainsi, par exemple, si nous avons un environnement à gauche où les choses sont en baisse, nous pouvons subir des pertes financières. Nous avons des implications juridiques qui peuvent être des implications commerciales au niveau de la stratégie commerciale.

Il y a toutes sortes de problèmes, je suppose, même moraux concernant les avantages d'un service. S'il s'agit d'une industrie de la santé et qu'ils commencent à subir le coût d'une panne, l'impact sur les clients, la réduction de la satisfaction client, la productivité du personnel, la productivité des utilisateurs, etc. Ces choses sont impactées si nous pensons à la conception hautement complexe, très dépendante, environnement très risqué où il existe un risque potentiel de panne et donc de perte.

Du côté droit, nous essayons de viser un scénario où, si nous investissons des coûts élevés et une planification dans la conception, nous investissons dans une mise en œuvre intelligente. Nous investissons dans la fourniture de compétences et de ressources aux personnes et nous avons un réseau hautement apprécié et un environnement opérationnel et matériel et logiciel hautement appréciés. Nous obtenons une haute disponibilité mais cela a un coût élevé. Ainsi, le point de pendule magique oscillant de la position optimale au milieu où ils se croisent, où nous avons un coût légèrement réduit, et une disponibilité croissante qui jongle simplement entre les niveaux de neuf et la haute disponibilité qui est une disponibilité continue et ceci est un un défi constant à relever, comme dans combien d'argent vous êtes prêt à investir pour obtenir le niveau de service que vous recherchez?

Nous avons également le sujet sur lequel je n'entrerai pas dans les détails, mais je veux juste que vous en retiriez et que vous y réfléchissiez. La différence entre le temps moyen entre l'échec de votre conception et le temps moyen de récupération. En d'autres termes, investissez-vous dans une infrastructure de meilleure qualité, une conception de meilleure qualité, du matériel et des logiciels de meilleure qualité et un personnel et des ressources qualifiés de meilleure qualité pour concevoir les choses et réduire le temps moyen entre les pannes, le temps moyen qu'il faut pour trouver la rupture par opposition réduire les investissements dans les infrastructures, les ressources et la conception et les brevets aveugles, la grande capacité de récupération? En d'autres termes, si quelque chose se casse, vous en avez beaucoup à brancher. Si quelqu'un a un ordinateur portable et qu'il meurt, vous en avez un de rechange. Vous le leur remettez et en 30 secondes, ils se connectent. Ce sont des extrémités très différentes du poteau. Celui du haut laisse entendre que votre ingénierie a un coût élevé et un investissement élevé pour éviter l'échec, et celui du bas dit: «Je vais accepter que l'échec va se produire, donc je vais concevoir cela et être prêt à l'échec. et récupérer rapidement. "

Comme je l'ai mentionné précédemment, où je pourrais dire: «Ma disponibilité n'est pas votre disponibilité». Donc, quand il s'agit d'environnements de base de données et de prise en charge de l'infrastructure, de gestion de votre base de données et de protection et de garantie de haute disponibilité, il n'y a vraiment pas de guichet unique . Chacun a ses propres besoins et désirs. Vous devez donc vous poser ces questions fondamentales que je vais vous laisser, à savoir: que peut se permettre votre organisation? Je ne parle pas seulement de dollars et de cents. Je parle, en tant qu'organisation, que pouvez-vous, en termes de ressources, de temps et d'efforts, etc., autant que le niveau de disponibilité peut offrir? Aussi, que peut soutenir votre entreprise? Donc, les capacités actuelles, les compétences actuelles, l'infrastructure actuelle, le financement actuel que vous pouvez collecter. Donc, ce qui jongle entre ce que vous pouvez réellement vous permettre et ce que vous pouvez soutenir est un équilibre intéressant.

De plus, vous devez alors vous poser les questions suivantes: Quelles compétences et technologies possédez-vous en interne? Pouvez-vous externaliser une partie de ce défi? Pouvez-vous ensuite déplacer des éléments vers le cloud? Si vous avez le service d'infrastructure en dehors du service logiciel, vous vous retrouvez sans cette pile au fur et à mesure que vous montez dans la pile. Donc, devriez-vous investir davantage dans les plates-formes et les services et ne pas vous soucier de la partie infrastructure, ou devriez-vous considérer les logiciels comme une offre de services parce que vous n'auriez pas à vous soucier de la plate-forme?

Quel type de marché et de consommateur ou de client desservez-vous? Je veux dire, si vous êtes un opérateur de télécommunications et que quelqu'un doit décrocher le téléphone et que vous obtenez une tonalité tout le temps, c'est un défi très différent pour ouvrir un petit magasin de détail entre lundi et vendredi, de neuf à cinq heures et fermer pour un heure le midi comme un barbier du dépanneur. Vous devez donc réfléchir très longuement et durement à la façon dont cela fonctionne et à ce que cela signifie pour votre organisation, ce que vous devez être en mesure de fournir.

Et puis jongler entre ce qui se trouve sur les lieux, ce qui est hébergé en externe et potentiellement, ce qui est dans le cloud. Comme je l'ai déjà dit, cela vient aussi des défis temporels. Nous sommes donc laissés à cette dernière question que j'attends avec impatience pour nos amis à IDERA pour nous dire comment ils abordent ces mêmes choses, et c'est le bon jonglage entre l'adéquation de votre disponibilité souhaitée et requise avec la performance, et ce dont votre entreprise a besoin et ce votre marché et vos consommateurs ont besoin.

Et la réalité est que ce n'est pas un mince exploit. Il faudra du temps, des efforts et de l'argent pour réfléchir à ces choses. Et invariablement, c'est un investissement dans les ressources humaines et les compétences et l'investissement dans des logiciels et des outils pour automatiser certains de ces processus et fournir à ces personnes les bons outils et les bons systèmes pour améliorer leur vie non seulement mieux, mais aussi parce que la surveillance des environnements à très grande échelle et la protection et la gestion de ces environnements à grande échelle dépasse souvent les capacités humaines individuelles.

Donc, avec cela à l'esprit, j'espère avoir préparé le terrain pour une grande conversation pour nos amis sur IDERA pour parler de leur plate-forme et de leurs outils, et j'ai hâte de poser quelques bonnes questions à la fin. Et je vais passer outre.

Dr Robin Bloor: D' accord. Bert, je viens de te donner les clés, prends-les.

Bert Scalzo: Merci! Merci, Dez et Robin. Je vais continuer avec le sujet de la haute disponibilité pour vos données. Et je vais en fait tirer parti de beaucoup de ce dont Dez vient de parler. Donc, les choix, les neuf, les compromis, l'abordabilité. Je vais essayer de mettre cela plus en termes à l'administrateur de la base de données ou quelqu'un plus proche des tranchées, comment ils le verraient? Comment pourraient-ils le concevoir? Et ce que ces choix signifient en quelque sorte.

Maintenant, je vais essayer d'être indépendant de la base de données. Je ne vais pas dessiner, par exemple, une solution spécifique à Oracle ou spécifique à SQL-Server, mais je vais dessiner, disons, une architecture générique que tous les fournisseurs de bases de données proposent, quelque chose dans ce sens. Ils l'appellent tous par des noms différents, mais c'est un type de choix que vous avez en commun, et je veux examiner cela à la fois du point de vue commercial et technologique, et comment cela se rapporte aux exigences commerciales.

Et je veux partir de ce qu'est la solution de pseudo-haute disponibilité la plus élémentaire à travers les options que vous avez aux solutions au niveau du stockage, des solutions au niveau de la virtualisation, aux solutions au niveau de la base de données. Et puis, je veux également vous présenter le fait que tous les choix sont également disponibles dans le cloud.

Donc, encore une fois, je vais essayer de rester assez indépendant des bases de données. Maintenant, la plupart des choses dont je vais parler, je sais qu'elles existent dans Oracle, SQL Server, MySQL, PostgreSQL. Il existe également des fournisseurs tiers, qui créent des outils qui vous fourniraient également des architectures supplémentaires que vous pourriez envisager. Et, comme vient de le dire Dez, aucune solution n'est la meilleure; tout dépend. Mais il y a un fait universel dans ce que nous allons examiner, c'est qu'il y aura plus de pièces mobiles, donc ce sera plus complexe et donc plus coûteux.

Donc, nous savons tous que les données sont un atout important. Et tout le monde sait qu'un accès rapide aux données est toujours agréable. Mais, un accès fiable aux données est essentiel. Et comme il en parlait avec ses neuf exemples, pouvez-vous vraiment vous permettre d'avoir 36½ jours de temps d'arrêt? Il est essentiel que ces données soient disponibles en permanence. Ainsi, les temps d'arrêt peuvent coûter une fortune, à la fois en termes de perte de revenus, mais plus important encore, en termes de clients perdus ou de perte de clientèle. Je vais vous donner un bon exemple; si un site Web particulier où je fais des achats est lent, je peux essayer de trouver un nouveau site Web qui vend des articles similaires à un coût similaire et qui n'a pas de sites Web lents. Et donc, ce n'est pas seulement la perte du client, c'est la bonne volonté que le client a envers vous.

Maintenant, le matériel est beaucoup moins cher de nos jours, donc il y a de plus en plus de demande pour une haute disponibilité. Et encore une fois, je vais nous conduire vers le cloud, quand on regarde ça. Et nous avons des offres à différents niveaux: les fournisseurs de stockage, les fournisseurs de bases de données, les fournisseurs de virtualisation et maintenant même les fournisseurs de cloud. Et donc, ce qui est vraiment intéressant avec le cloud, c'est après avoir dessiné toutes ces merveilleuses images de ces architectures que vous pouvez créer dans le cloud, souvent ce ne sont que quelques cases à cocher que vous cochez. Et vous dites: «Je veux une réplication dans toutes les régions géographiques». Case à cocher. «Je veux la réplication des composants matériels clés.» Case à cocher. Et donc, si vous comprenez les images, parfois dans le nuage, il suffit de cocher quelques cases pour créer l'image que vous avez en tête.

Maintenant, l'essentiel est, quelles sont les exigences commerciales pour une haute disponibilité? Par exemple, dois-je seulement m'inquiéter d'une défaillance sur un seul site ou dois-je l'avoir sur plusieurs sites? En d'autres termes, puis-je avoir un centre de calcul et je me fiche que ce centre soit hors ligne? Je n'exige pas de l'entreprise qu'elle s'étende sur plusieurs sites. C'est une question commerciale. Et il est important de savoir comment l'entreprise perçoit les réponses à cette question, car cela définit généralement votre budget.

Maintenant, vous voulez également regarder le niveau de protection contre les pannes. Serait-ce une panne de courant? Serait-ce une défaillance d'un composant? Comme une carte réseau ou un adaptateur de bus hôte va mal, un adaptateur de bus hôte. Est-ce un disque dur qui tourne mal? Est-ce une défaillance de l'armoire de stockage? Est-ce une panne d'ordinateur? Ou, dans certains cas, s'agit-il d'une défaillance du site? C'est différent de ce que, dans certains cas, vous pouvez avoir une défaillance du site, car le site lui-même est hors ligne. Dans un autre cas, il se peut qu'une partie substantielle du site soit hors ligne, mais de votre point de vue, c'est l'ensemble du site.

Et puis, comme Dez en parlait, à quoi s'attend-on du temps pour reprendre ses opérations? C'est une question commerciale. Si l'entreprise dit que vous devez être en mesure de reprendre les opérations dans les deux minutes, alors évidemment, cela va définir certaines de ces images que je vais montrer que vous travaillerez, et certaines d'entre elles ne seront pas des options que vous peut choisir.

Et une autre question qui se pose lors de la haute disponibilité, mais souvent les gens oublient de se demander: "Hé, affaires, si quelque chose se passe alors que je suis en train de traiter une transaction, qu'est-ce que je peux perdre à la reprise du système? " En d'autres termes, si je peux rétablir le système en deux minutes et que je ne peux pas perdre plus de 10 secondes, disons, de transactions en cours, est-ce acceptable? Et encore une fois, cela définira ce que l'entreprise est prête à dépenser pour cela, et encore une fois, cela peut définir quelles images que je vais vous montrer s'appliquent ou ne s'appliquent pas.

Commençons donc par la solution de pseudo haute disponibilité la plus basique. Ce n'est vraiment pas une haute disponibilité, mais j'aime commencer par cela, car cela amène les gens à penser dans le bon sens. Si j'ai un serveur et une matrice de stockage, je place généralement plusieurs cartes réseau, cartes d'interface réseau sur ce serveur et je les lie de sorte que si une carte réseau tombe en panne, je suis toujours opérationnel. Et je ferai la même chose avec mes adaptateurs de bus hôte, je les acheminerai par plusieurs commutateurs, afin d'avoir plusieurs façons d'accéder à mon stockage. Et j'ai une alimentation universelle, et j'ai des contrôleurs répétitifs à l'intérieur de ma matrice de stockage, et peut-être que j'ai fait quelque chose comme RAID 10 avec mes disques. En d'autres termes, dans cette image, j'ai empêché la défaillance d'un composant à plusieurs niveaux. Donc, je ne suis pas lié par le NIC, ou le HBA, ou le contrôleur, ou le commutateur.

Mais si vous remarquez, le serveur est en rouge et la baie de stockage est en rouge. J'ai encore deux domaines où s'ils échouent, si mon serveur tombe en panne, je suis mort, si mon armoire de stockage disparaît, je suis mort. Ainsi, bien que ce ne soit pas vraiment une haute disponibilité, cela vous amène à voir et à regarder l'image et à dire: "Je veux une image où il n'y a pas de rouge." Et c'est vraiment le but de ces photos, de nous faire pointer dans la bonne direction.

Donc, la première chose qui se passe est qu'en tant qu'administrateur de base de données, je pourrais toujours vouloir mettre la solution à haute disponibilité en tant qu'implémentation de base de données, mais il se peut qu'elle soit disponible qu'elle puisse être effectuée en tant que solution de stockage, ou qu'elle soit qu'il pourrait s'agir d'une réplication au niveau du stockage. Dans le cas de la gauche, j'ai la virtualisation du stockage. Ce qui se passe, c'est que j'ai RAID 0 dans deux armoires de stockage différentes pour mes disques, mais j'ai RAID 1 sur les deux armoires de stockage différentes. En d'autres termes, je peux maintenant faire échouer une armoire de stockage et je ne suis pas mort. Donc, c'est mieux que l'image précédente, car dans l'image précédente - rappelez-vous que nous avions à la fois du rouge sur le serveur et du rouge sur la baie de stockage - et maintenant nous avons fait une petite amélioration, nous n'avons plus de rouge au niveau du stockage, nous 'ai utilisé - la virtualisation du stockage a résolu ce problème.

Maintenant, une autre façon de le faire - et tous les fournisseurs ne le fournissent pas - est que vous puissiez effectuer une réplication au niveau du stockage. Je ne parle pas de réplication de base de données, je parle en fait de réplication de vos E / S de bloc pour votre stockage. Et cela peut se faire au niveau du stockage. Et encore une fois, j'ai maintenant sur le côté droit, une autre image où je supprime le rouge du bas, car j'utilise la réplication de stockage.

Et donc, c'est une autre image qui peut ou non être disponible. Et la personne qui gérerait cela pourrait être votre administrateur de stockage, plutôt que votre administrateur de base de données. J'aime soulever cette question, car parfois les gens pensent: "Oh! Haute disponibilité, ce doit être le DBA qui résout ce problème." Cela n'est pas toujours vrai; il pourrait dans ce cas être l'administrateur du stockage.

Maintenant, nous pouvons faire de la virtualisation des serveurs une solution possible. Maintenant, si vous vous souvenez, dans la première image, j'avais rouge sur le serveur et rouge sur la baie de stockage. Je pourrais, dans ce cas, utiliser la virtualisation, je pourrais être en mesure de déménager, et dans certains cas, cette relocalisation est une sorte de relocalisation à chaud, et dans certains cas, peut même être une relocalisation à chaud. Certaines virtualisations ou hyperviseurs offrent la possibilité de déplacer une machine virtuelle en vol. Et certaines bases de données accepteront facilement ce mouvement en vol. Maintenant, encore une fois, tous les hyperviseurs ne fournissent pas cela, mais c'est un niveau de solution possible. Maintenant, j'ai fait que les serveurs supérieurs ne sont plus rouges, mais j'ai toujours la baie de stockage partagée et devinez quoi, cette solution peut être un effort conjoint entre l'administrateur de la base de données et l'administrateur de la virtualisation. Ou il peut même s'agir uniquement de l'administrateur de virtualisation, selon le niveau de relocalisation pris en charge sur cet hyperviseur et cette base de données.

Si vous vous demandez: «Wow, que veut-il dire par cette relocalisation? Donnez-moi un exemple spécifique. »Par exemple, dans VM où vous pouvez utiliser VMotion pour déplacer votre machine virtuelle d'un hôte à un autre et le faire sans temps d'arrêt. Maintenant, il est clair que cette photo précédente contenait encore du rouge. J'avais toujours le stockage comme étant un point de défaillance unique. Et donc nous passons à la solution suivante qui est, eh bien, permettez-moi de combiner le stockage et la virtualisation du serveur.

Maintenant, dans ce cas, encore une fois, ce pourrait être l'administrateur de stockage et l'administrateur de virtualisation qui construisent cette solution et regardent maintenant: J'ai une image sans rouge. J'ai une haute disponibilité car je peux déplacer la machine virtuelle ou l'application ou la base de données en cours d'exécution d'un serveur à un autre et j'ai la virtualisation dans ma matrice de stockage en la faisant faire RAID 1 sur deux baies de stockage distinctes. J'ai multi-cheminé mes commutateurs et mes HBA.

Alors maintenant, j'ai construit un système HA et je l'ai fait principalement pas au niveau de la base de données. En d'autres termes, j'ai utilisé d'autres technologies pour accomplir la même chose. C'est donc une solution. Ensuite, nous entrons dans ce qu'on appelle le cluster évolutif de stockage partagé. Ce n'est vraiment pas une solution HA, mais encore une fois, j'aime le montrer pour l'image.

Et ce qui se passe ici, c'est que nous avons deux serveurs exécutant une base de données et il est considéré comme une seule base de données. Ce ne sont pas deux bases de données distinctes; ce n'est pas comme un maître et un esclave, ni un chaud et un froid, ni un actif et un veille. C'est-à-dire que ces deux nœuds travaillent ensemble pour présenter une base de données logique. Et donc, ce qui se passe, c'est que si un nœud particulier tombe en panne, vous êtes toujours opérationnel. Ainsi, il vous protège contre les défaillances au niveau du serveur et le fait essentiellement, en quelque sorte, en partageant les ressources du nœud, si vous le souhaitez, mais vous avez toujours le point de défaillance unique pour le disque. Et donc, il s'agit d'un cluster évolutif à stockage partagé et Oracle appelle ce Real Application Cluster ou RAC.

Maintenant, une autre solution consiste à utiliser un cluster de basculement de stockage partagé. Donc, à gauche, j'ai un nœud actif, à droite, j'ai un nœud passif, j'ai un battement de cœur entre les deux. J'ai une baie de stockage partagée, ce qui est essentiel; vous devez avoir cela. Et fondamentalement, ce qui se passe, c'est que si le nœud actif rencontre des problèmes, le nœud passif peut prendre le relais. Il y a des problèmes de licence à cela. Certains fournisseurs de bases de données vous permettent d'avoir le nœud passif avec une licence réduite pour une durée fixe. Dans d'autres cas, vous devez disposer d'une licence en double complète. Tout dépend du fournisseur de votre base de données. Mais ils supportent tous ce genre d'image qui est, si un nœud tombe en panne, l'autre nœud peut prendre le relais.

Et généralement, c'est l'un de ces scénarios où c'est en quelque sorte, lorsque vous passez du nœud actif au nœud passif, vous allez probablement, dans la plupart des bases de données - pas toutes - vous allez perdre une partie de l'in- transactions aériennes. Ensuite, nous abordons ce que l'administrateur de base de données peut vraiment regarder, à savoir la réplication de base de données, et il existe deux façons différentes de faire la réplication de base de données.

Il y a une réplication physique, et ce qui est important, au milieu de cette image, vous pouvez voir avec l'étoile verte, que la réplication, elle est effectuée par la base de données mais, tout comme la virtualisation au niveau du stockage, elle se fait au bloc niveau. Nous répétons donc les E / S de bloc réelles du nœud actif au nœud en lecture seule ou passif. Et cela est considéré comme une réplication physique.

Maintenant, laissez-moi passer à la diapositive suivante, car elle est presque identique et c'est une réplication logique et la seule chose qui change dans l'image est qu'au milieu, au lieu d'envoyer sur le bloc d'E / S, nous envoyons essentiellement sur le journal fichiers contenant les commandes SQL. En d'autres termes, ce que nous répliquons n'est pas les E / S physiques, mais les commandes qui provoquent les E / S physiques.

Et donc, cela est souvent appelé expédition de journaux ou réplication basée sur les journaux. Certains fournisseurs de bases de données vous fournissent cela nativement. D'autres fournisseurs de bases de données peuvent ne pas offrir cela, mais des fournisseurs tiers l'offrent, et c'est donc une solution HA très populaire et considérée comme une solution complète. Mais cette solution relève principalement de la responsabilité du DBA.

Donc, je n'utilise pas la virtualisation pour y parvenir. Je pourrais, mais je n'en dépend pas. Et je n'utilise pas la virtualisation du stockage. Encore une fois, je pourrais, mais je n'en suis pas dépendant. Mais je construis une solution avec la base de données comme principale fonctionnalité de conduite. Il s'agit donc d'une réplication logique.

Désormais, il est également possible de combiner la virtualisation de la base de données et du stockage. Je pourrais avoir, dans mon centre de données, disons, à gauche en bleu, je pourrais avoir la virtualisation pour le stockage afin que je ne sois pas lié à une baie de stockage particulière en échec. Mais je fais peut-être une réplication logicielle ou logicielle au niveau de la base de données d'un centre de données à l'autre afin que les commandes soient également exécutées dans le centre de données, ce qui entraîne des E / S, mais pas nécessairement les mêmes E / S, car je ' Je n'envoie pas sur les E / S de bloc, ni par la solution de stockage ni par la base de données, mais j'expédie les journaux, et donc les commandes SQL.

Et donc, c'est une image qui est une image très courante pour les très grandes organisations. Et j'aime cette image ici parce que si je dois configurer cela sur place en utilisant une base de données comme Oracle, je peux le faire; c'est beaucoup de travail, c'est assez complexe, il y a beaucoup de pièces mobiles. Si je fais cela dans le cloud, je peux littéralement dire simplement, case à cocher, je veux deux régions géographiques, je veux que les régions soient séparées par, vous savez, sur différents continents, je veux une virtualisation au niveau du stockage dans une région géographique particulière. Je peux même dire que je veux pouvoir effectuer une allocation de type de virtualisation ou une définition de haute disponibilité, et encore une fois, c'est une autre case à cocher.

Et l'autre chose que j'aime dans le cloud, il y a souvent une autre case à cocher pour dire: «Je ne veux pas gérer les correctifs, corrigez-les simplement», vous savez, intégrez-les simplement au flux de travail de tout ce que vous faites derrière le scènes, gardez-moi à tout moment patché. Et donc, alors que certaines de ces images deviennent très complexes et qu'elles peuvent être très difficiles à faire sur place, elles deviennent en fait assez faciles à faire dans le cloud.

Maintenant, la chose intéressante est qu'il est facile de cocher toutes les cases, mais devinez quoi, cela coûte plus d'argent sur une base mensuelle. Parce que si vous utilisez deux centres de données, vous savez, vous avez deux centres de données dans le cloud que vous utilisez, vous allez payer plus que si vous n'en utilisiez qu'un. De même, si vous faites le niveau de stockage ou la haute disponibilité de virtualisation en tant que couche supplémentaire, là encore, il peut y avoir des coûts supplémentaires.

Donc, il est intéressant de noter que même si c'est difficile à faire sur place et que vous pouvez y penser de manière excessive, dans le cloud, c'est si facile à faire, vous pouvez y penser moins. Donc, sachez toujours à quoi ressemble l'image et sachez toujours quelles sont les ramifications des coûts pour l'image que vous construisez. Maintenant, il y a beaucoup plus de combinaisons que ce que j'ai montré ici. Ce n'est pas un exemple complet ou exhaustif. Il y a de nouvelles technologies à venir à intervalles réguliers, alors qui sait - je n'en ai peut-être pas montré une qui vient de faire son apparition au cours des trois derniers mois. Et la haute disponibilité est beaucoup plus courante qu'elle ne l'était il y a dix ans.

En fait, je ne considérerais pas exagéré de dire que pour la plupart des grandes organisations, c'est une exigence commerciale obligatoire de nos jours. Et j'aime revenir à cette diapositive parce que je viens de dire que c'est une exigence commerciale obligatoire. Et j'ai ces deux tableaux à droite. Le premier est sorti de la documentation SQL Server et le bas est sorti de la documentation Oracle. Et ce sont des tableaux pour vous aider à choisir la méthode de réplication à utiliser.

Et notez que vous commencez par des questions très simples. Combien de données suis-je autorisé à utiliser? Et si la réponse est zéro, vous savez que vous ne pouvez que, dans ce graphique du haut, choisir la première ou la quatrième ligne. Ensuite, vous posez une autre question. Eh bien, combien de temps ai-je le droit de prendre pour la récupération? Et si quelqu'un dit, eh bien, secondes ou minutes, alors cela fait des choix pour vous. Et puis, le basculement doit-il être automatique ou faut-il que quelqu'un le fasse manuellement? Et c'est une autre question commerciale. Ils peuvent dire qu'ils veulent que ce soit automatique parce qu'ils ne veulent pas s'appuyer, vous savez, sur une procédure d'escalade, puis sur quelqu'un qui se voit attribuer un ticket et ensuite résoudre le problème. Ils veulent juste que ce soit corrigé.

Ce sont toutes des questions commerciales et ce sont les mêmes questions si je descends et fais la même chose pour Oracle. Et je demande, OK, quel genre de défaillance puis-je autoriser, quel type de durée, que puis-je perdre, quelle est la procédure de récupération? Ce sont tous des choix commerciaux, donc si l'entreprise me dit les réponses à trois ou quatre questions, mon travail est vraiment facile, je viens ici, je choisis celui qui correspond le plus et je le construis. Et rappelez-vous, dans le cloud, il ne peut y avoir que quelques cases à cocher pour les mettre en œuvre.

Et avec cela, cela m'amène à la fin de mon matériel et le temps de l'ouvrir à des questions.

Eric Kavanagh: D' accord, Dez, peut-être vous d'abord et ensuite Robin?

Dez Blanchfield: Absolument. En fait, probablement un peu injuste pour ceux qui ne sont pas sur Twitter, mais je viens de tweeter une image d'un graphique que je veux visualiser dans l'esprit de tout le monde et je voulais ensuite poser la question à notre confrère lors de l'appel ici. Quand je pense à la propriété exclusive par rapport à l'open source dans cet espace - qui est souvent ce dont nous parlons, en quelque sorte, des bases de données propriétaires comme Oracle et Microsoft et ainsi de suite, par rapport à l'open source - vous vous retrouvez avec ce défi dans lequel le monde propriétaire le fournisseur de logiciels Internet ou le développeur de logiciels ou l'entreprise investit dans les corps pour construire cette complexité. Et donc, vous vous retrouvez avec un scénario où vous achetez le logiciel et vous n'avez pas besoin d'investir dans beaucoup de gens parce que vous achetez la capacité intégrée et en open source - vous ne payez pas pour le logiciel ou son faible coût, disons, mais vous ne payez pas pour le logiciel, mais vous devez investir dans les corps.

Et je suis impatient d'avoir votre avis sur le jonglage, en particulier maintenant que nous entrons dans des modèles de cloud où vous pouvez obtenir soit / ou. Vous pouvez accéder à AWS ou Azure et à votre Rackspace, peu importe, et acheter en tant que service qui fournit votre plate-forme de base de données, ou vous pouvez le faire via du code open source. Et ce dont nous venons de parler, quel est le jonglage entre propriétaire et open source et comment les modèles de conception dont vous parlez prennent effet et quelles sont vos réflexions générales sur ce sujet à mesure que nous progressons, en particulier en ce qui concerne la disponibilité?

Bert Scalzo: L'un des gros éléments que je rencontre lorsque j'essaie de répondre à cette question, je retourne vers le client et lui demande quelles sont ses exigences de performance. Et la raison pour laquelle je fais cela, c'est que j'ai constaté - au moins historiquement et selon ma propre expérience - que lorsqu'il s'agit de clients qui ont besoin d'un débit élevé sur leur réplication, je suis presque toujours mieux avec la réplication fournie par la base de données fournisseur, en raison de sa nature intrinsèque et de son niveau inférieur, et parfois il utilise des mécanismes qui ne sont pas disponibles pour le monde extérieur, même dans une solution open source.

Et je vais vous donner un bon exemple d'un cas que j'ai eu. J'avais une entreprise basée sur Internet qui utilisait MySQL comme base de données et ils étaient sur une ancienne version de MySQL, comme la version 4.0, et la réplication entre leurs nœuds était le facteur limitant sur la taille de leur base de données. Et ils envisageaient d'acheter une solution tierce, puis ils se demandaient: «Eh bien, nous pouvons peut-être utiliser l'une des solutions open source». Et ce qui se résumait vraiment à cela, tout ce qu'ils avaient à faire était de mettre à niveau leur MySQL vers la version, je pense que c'était la version 5.5 vers laquelle nous sommes allés, car la différence entre ces deux versions de base de données était dans la version 4.0 de la réplication MySQL n'était pas enfilée dans la version 5.0, c'était le cas, et c'était en fait le meilleur chemin pour eux.

Maintenant, nous avons examiné les autres choix, mais le facteur décisif était la performance et le maintien de la solution du fournisseur de base de données, et la mise à niveau de la base de données a finalement été notre meilleure solution pour obtenir la plus grande probabilité d'obtenir les performances dont ils avaient besoin. la plus grande disponibilité.

Dez Blanchfield: Oui, cela reflète ma propre pensée, pour être honnête. Juste pour une divulgation complète, et je n'entrerai pas dans les marques, mais je viens d'un milieu propriétaire travaillant pour les OEM et les fournisseurs de logiciels et les IOC en général, et c'est certainement mon expérience et en même temps je suis très pro -open-source et je suis un contributeur de code pour un tas de projets que nous ne nommerons pas, mais je suis d'accord avec vous en ce que si vous êtes une grande organisation - disons que vous êtes une banque, ou quoi que vous puissiez soyez - invariablement, vous ne voulez pas être un magasin informatique. Vous savez, par exemple, si vous êtes un éditeur de journaux ou si vous êtes un détaillant, vous ne voulez pas être un magasin informatique qui publie des journaux, vous voulez être un magasin de journaux qui ne fait que tirer parti de l'informatique.

Et donc, investir dans les capacités propriétaires où les développeurs de logiciels développent toutes ces capacités, l'équilibrage de charge, etc. dans l'outil, est beaucoup plus logique que si vous êtes, comme, une startup dotcom ou quelque chose du genre comme ça qui peut investir dans le corps humain. Où voyez-vous cela?

Probablement ma dernière question avant de passer la parole au Dr Robin Bloor, car je sais que nous manquons de temps. Où voyez-vous cela d'un point de vue tendance? Donc, vous êtes là tout le temps, vous êtes à la pointe du progrès, voyez-vous que les gens se sont assis et ont fait attention et se sont rendus compte de la nécessité d'en faire une partie commerciale de leur quotidien. conversation d'une journée à la salle du conseil? Ou voyez-vous toujours que c'est vraiment la ferme des geek, les techniciens et les hoodies pensent à la disponibilité parce que cela les fait se réveiller à quatre heures du matin quand quelque chose se passe hors ligne?

Pensez-vous que la tendance se propage maintenant aux organisations de toutes tailles, pas aux organisations évidentes comme les compagnies aériennes et les banques et la finance, mais uniquement aux entreprises en général? Pensez-vous que les gens sont vraiment sortis de la proposition de valeur pour protéger leurs environnements de base de données et fournir une haute disponibilité et investir dans cela, ou pensez-vous que nous avons encore du chemin à faire? Quel est le sens général du marché?

Bert Scalzo: À l'heure actuelle, je pense qu'il y a encore un écart, mais ce n'est pas un écart parce que l'entreprise ne le demande pas, c'est un écart dans les niveaux de communication entre les deux côtés de la clôture. En d'autres termes, les gens d'affaires disent très clairement: «Ces applications nécessitent une haute disponibilité et ont ces exigences spécifiques lorsque nous parlons de haute disponibilité.»

Et d'une manière ou d'une autre, ce message n'est pas clairement transmis aux techniciens. Ou les techniciens reviendront et diront: «Oh, eh bien c'est compliqué et ça vous coûtera plus d'argent», et ceci, cela ou l'autre. Je pense que ce qui va arriver, c'est que ça va finalement s'éroder parce que, honnêtement, avec cela, par exemple, dans le cloud, il suffit de cocher quelques cases ici ou là pour dire: «Construisez-moi cette structure technologique vraiment complexe», il y a vraiment aucune bonne raison pour que les gens de la technologie reviennent et disent aux gens d'affaires: "Oh, c'est cher" ou "C'est difficile à faire", ou ceci ou cela, et les gens d'affaires commencent à savoir que c'est le fait.

Et j'ai même vu dans des environnements où, vous savez, leurs propres informaticiens viendront et diront: «Oh, vous ne pouvez pas avoir ce que vous voulez. C'est trop cher. »Et ils feront venir un cabinet de conseil tiers qui dira alors:« Non, ce n'est pas correct. Voici comment vous pouvez le faire. Voici ce qu'il vous en coûtera. »Donc, je pense que nous avons encore un peu de temps entre les niveaux de communication entre les deux côtés avant que cela ne devienne automatique.

Dez Blanchfield: Oui, c'est certainement le reflet de ce que j'ai vu ici en Australie et dans la région Asie-Pacifique. Je suis sûr que c'est une chose globale. Et c'est que beaucoup de décideurs clés de la salle du conseil, tous les chefs de secteur, ils sont «beaucoup plus techniquement avertis - ils lisent les blogs, ils regardent des webinaires, ils sont à l'écoute de divers articles et podcasts et ils vont à des événements et des forums et des rencontres et ils connaissent maintenant leurs options et ils savent que le cloud est une option.

Ils savent aussi qu'ils peuvent apporter, comme vous l'avez dit, leurs capacités en interne, et donc je pense qu'il y a ce défi intéressant maintenant, cette conversation qui doit avoir lieu, qui est essentiellement ce que nous avons fait aujourd'hui où les gens, en quelque sorte, commencez à faire des choses en interne et lancez simplement des déjeuners avec des sacs bruns et faites un briefing interne sur notre état actuel, quel est notre état idéal, où devons-nous aller? Et puis, en quelque sorte, rassemblez cela.

J'avais un message privé que je vais aborder rapidement tout à l'heure. Quelqu'un a posé une question: «Est-il réaliste que vous puissiez obtenir une disponibilité à 100%?» Et vous pourriez peut-être me corriger ici, mais je vais dire oui. J'ai construit une plate-forme pour un transfert électronique de fonds, une passerelle EFTPOS entre les plates-formes bancaires rapides et les terminaux EFTPOS. Je l'ai construit au début des années 2000. Il est en fait en ligne 100% du temps depuis 17 ans. En fait, il a été construit avant les années 2000, mais il est entré en production en 2000/2001 à peu près.

Ainsi, les 17 années ont été en place, du développement aux tests, puis à la mise en production. Au cours de ces 17 années, des PC standard à très bas prix, exécutant un système d'exploitation open source, mais une base de données propriétaire, ont effectué des échanges actifs / passifs tous les 90 jours, avec différents brevets de conception appliqués, avec réplication de disques sur chaque serveur, réplication des données entre les serveurs modèles, réplication de plusieurs centres de données et basculement du centre de données A en production pendant 90 jours, puis basculement vers le centre de données B et production.

Et au fur et à mesure qu'il se retourne, il corrige et met à jour automatiquement, donc juste à la question que je viens de poser en privé, oui, c'est possible, mais avec beaucoup d'investissement dans ce projet d'un point de vue design. Donc, l'infrastructure n'était en fait pas si chère, mais la conception, les tests et la mise en œuvre coûtaient très cher pour l'obtenir. Nous n'avons donc pas eu à dépenser beaucoup d'argent en matériel et en infrastructure, mais nous avons utilisé des outils très intelligents, à l'époque où le cloud n'était même pas une monnaie.

Donc, la réponse est oui, cela peut être fait, encore plus maintenant avec le cloud, comme nous venons de l'entendre, en cliquant sur un bouton, vous pouvez activer cette capacité. Je vais lancer ça à Robin parce que je suis sûr qu'il a aussi des questions. Mais merci beaucoup d'avoir répondu à mes questions et j'ai vraiment adoré entendre votre message aujourd'hui. Complètement à bord avec tout cela, car il reflète tout ce que je fais depuis près de 30 ans.

Dr Robin Bloor: Eh bien, d'accord, je vais le ramasser. L'une des choses qui m'ont fasciné dans votre présentation était le nombre d'options disponibles maintenant qui n'étaient pas disponibles lorsque j'avais du mal avec ce genre de choses. Je suis un peu intéressé par qui va concevoir ces configurations, ou qui, de nos jours, conçoit ces configurations? Ce qui se passait auparavant, ou, dans le monde auquel je suis habitué, c'est qu'il y aurait un système transactionnel assez lourd et que vous seriez intéressé par une disponibilité élevée et une haute disponibilité. Parce que, vous savez, le système transactionnel, il coûterait cher s'il tombait en panne de quelque façon que ce soit. Et vous n'auriez pas toutes les options que vous venez de me présenter, mais d'une manière ou d'une autre, vous pourriez trouver un moyen, via la réplication principalement, de créer une redondance d'UC qui ne cliquerait pas de façon inaperçue, mais cela vous donnerait un service dégradé jusqu'à votre retour.

Et je suis en quelque sorte en train de regarder ce que vous me montrez et d'y penser, n'ayant pas fait ce genre de travail de conception depuis 15 ans, qui fait ce travail maintenant? Est-ce, comme c'était le cas à mon époque, quelque chose que vous avez fait au début d'un projet, vous savez, faire fonctionner l'infrastructure? Ou s'agit-il d'une activité continue au sein d'une organisation? Parce que de nouveaux choix technologiques se présentent.

Bert Scalzo: Dans les grandes entreprises qui sont très efficientes et efficaces dans toutes leurs opérations, y compris leur informatique, ils auront généralement un groupe d'architecture centralisée, ou ils auront un nom pour cela, je l'ai entendu appeler «le groupe d'architecture »à de nombreuses reprises. Et ce sera leur responsabilité de connaître toutes ces différentes images et quels sont les avantages et les inconvénients et quels sont les coûts. Et ce qui se passera, c'est quand une application particulière est à la recherche et dit: "Hé, je dois répondre aux exigences commerciales X, Y et Z. Hé, l'équipe d'architecture, quels sont mes choix?"

Ils leur donneront la réponse, comme, voici les deux ou trois qui sont disponibles, puis à ce stade, la décision revient au niveau inférieur à l'équipe d'application ou au sponsor commercial de l'application. Mais généralement, il y a un groupe centralisé qui reste au courant de cela et qui a ces informations à portée de main et prédéfinies.

Maintenant, ce sont les moyennes entreprises où ce n'est pas si formel. Ce qui aura tendance à se produire, c'est que vous obtiendrez un ou deux de vos administrateurs de base de données ou administrateurs système principaux et ils seront officieusement cités «l'expert du domaine» pour ce type d'expertise. Donc, même dans les moyennes entreprises, cela se produit, cela se produit simplement dans une structure non formalisée.

Dr Robin Bloor: C'est vraiment assez intéressant. À mon époque, nous ne penserions jamais à la haute disponibilité, sauf pour les systèmes transactionnels. Eh bien, de nos jours, bien sûr, vous avez des systèmes de streaming qui sont probablement soumis à des exigences encore plus grandes en termes de disponibilité. Mais, dans l'environnement de requête, le back-end, l'analyse, l'entrepôt de données et l'environnement de type DI, voyez-vous déjà des exigences de haute disponibilité?

Bert Scalzo: Oui, et je suis content que vous ayez posé cette question. J'ai travaillé pour une entreprise de vente au détail et leurs décisions stratégiques pour l'entreprise reposaient en grande partie sur l'analyse qu'elles feraient à partir de l'entrepôt de données. Et, en fait, ils ont été interviewés par Forbes Magazine et le PDG de la société a déclaré: «Hé, notre cours de bourse a augmenté de 250% au cours des cinq dernières années et une raison très importante qui est vraie est parce que nous savons comment exploiter efficacement nos données dans notre entrepôt de données. "Ils étaient si doués pour prendre des décisions commerciales que, pour eux, l'entrepôt de données et être en mesure de faire ces analyses, être en mesure de prendre des décisions quotidiennement par rapport à leurs données opérationnelles, était en fait, pour eux, un système de production.

Et je vais vous donner un bon exemple de son importance. Avec ce vendeur au détail en particulier, le gars qui était responsable des ventes de bière, il était, comme, le troisième dirigeant le plus important de l'entreprise, car il rapportait, vous savez, 60 à 70% des revenus. Et donc, il devait pouvoir, pour rester compétitif sur ce marché, il devait pouvoir savoir tous les jours, vous savez, quelles promotions devrais-je faire. Et cela pourrait être basé, vous savez, non seulement sur la période de l'année, mais aussi sur la météo, les modèles et d'autres données critiques qui peuvent affecter la vente de quelque chose comme la bière.

Dr Robin Bloor: Eh bien, je suppose qu'il doit y avoir des choses comme ça. Nous sommes un peu à court de temps, je pense que je devrais passer la main à Eric au cas où il aurait des questions du public. Eric?

Eric Kavanagh: Oui, tout cela a été génial, Bert. Je pense que vous avez répondu à toutes les questions que nous avons posées à l'auditoire dans votre exposé. Mais c'est amusant à regarder. Je suis heureux que vous ayez en quelque sorte parlé de la virtualisation du stockage et de l'impact que cela peut avoir. Donc, ce sont toutes de bonnes choses.

Eh bien, les amis, nous archivons toutes ces webémissions pour une visualisation ultérieure. Alors, accédez en ligne à Techopedia.com pour rechercher la section de diffusion sur le Web. Tous ces Hot Techs y seront répertoriés. Un grand merci à notre ami Bert pour son expertise. Et bien sûr, à Dez et Robin. Et avec cela, nous allons vous dire adieu, les amis. Prends soin de toi. Nous vous parlerons la prochaine fois. Bye Bye.

Protégez votre base de données: haute disponibilité pour les données à forte demande