63 : Nutanix Weekly : Honey I Shrunk My Cluster (Multiple Nodes Down in RF2)

WEBVTT

1
00:00:02.270 -> 00:00:19.830
Andy Whiteside : Bonjour à tous ! Bienvenue dans l'épisode. 63 de la semaine du nouveau tennis. Nommez votre animateur, Andy White Side, nous sommes le 12 décembre, 2 022 et j'ai une grande équipe de gars intelligents. Harvey Green, mon co-animateur depuis probablement le premier jour. Etiez-vous déjà au premier jour, je ne me souviens pas. J'ai l'impression que oui. Mais

2
00:00:20.050 -> 00:00:24.560
Harvey Green : qui sait ?

3
00:00:25.180 -> 00:00:30.590
Andy Whiteside : Harvey, c'est votre premier mois de décembre, vous dirigez une entreprise, vous dirigez toute l'entreprise Gov.

4
00:00:30.660 -> 00:00:33.099
Andy Whiteside : vous savez que la folie s'annonce, n'est-ce pas ?

5
00:00:33.140 -> 00:00:35.100
Harvey Green : Oui, 100%.

6
00:00:35.600 -> 00:00:48.029
Harvey Green : C'est déjà fait. Je ne veux pas vous effrayer, mais cela signifie que vous gagnez de l'argent tant que les gens paient leurs factures. Je ne veux pas vous effrayer, mais cela signifie que vous gagnez de l'argent tant que les gens paient leurs factures. Oui, c'est exact.

7
00:00:48.120 -> 00:00:54.029
Harvey Green : C'est toujours la mise en garde. C'est toujours le cas. C'est un peu la façon dont la plupart des entreprises fonctionnent, je pense. Je pense que c'est ainsi que fonctionnent la plupart des entreprises.

8
00:00:54.230 -> 00:01:06.550
Andy Whiteside : Oui, c'est vrai. J'ai écrit ce livre sur un détaillant, un détaillant de l'an 2000. Vous appréciez peut-être l'Amérique. Je ne m'en souviens pas. Je ne m'en souvenais pas, et je m'en souviens maintenant que c'est le livre.

9
00:01:06.880 -> 00:01:13.319
Andy Whiteside : Mais cela me rappelle le nombre d'entreprises qui se contentent de créer des revenus parce qu'elles essaient de se vendre le plus rapidement possible.

10
00:01:13.490 -> 00:01:14.789
Andy Whiteside : et

11
00:01:15.300 -> 00:01:18.409
Andy Whiteside : vous savez. Et quand vous devez payer vos propres factures, c'est un autre monde.

12
00:01:20.380 -> 00:01:26.210
Jirah Cox : Oui, je pense que vous êtes soit fondamentalement dans ce modèle où ce sont les clients qui paient les factures, soit je suppose que vous dirigez une agence de recouvrement.

13
00:01:26.250 -> 00:01:27.730
Jirah Cox : Ce sont en quelque sorte vos deux choix.

14
00:01:27.770 -> 00:01:32.209
Andy Whiteside : Eh bien, 100%. C'est l'intégrale. Il en fait beaucoup. Nous retrouvons beaucoup de paiements.

15
00:01:32.480 -> 00:01:38.270
Philip Sellers : Je pense que c'est le cas. En fin de compte, c'est ce que font toutes les entreprises, à moins que vous ne payiez d'avance ou autre chose. Philip Sellers. Comment cela se passe-t-il ?

16
00:01:38.690 -> 00:01:40.690
Philip Sellers : Bien ! Comment allez-vous ? Bien !

17
00:01:40.740 -> 00:01:42.350
Andy Whiteside : Vous êtes donc

18
00:01:42.930 -> 00:01:55.779
Andy Whiteside : venant du côté client, le Vmware du client Vmware. Plus précisément, la nouvelle pièce des réservoirs est quelque chose. Vous l'avez toujours regardé de loin avec envie. Ou est-ce que c'est vraiment la première fois que vous entrez dans le monde de la Newtonique ?

19
00:01:56.420 -> 00:02:09.770
Philip Sellers : J'ai passé une journée avec Gyra au siège de Durham le mois dernier, et il a fait de moi un croyant. oui, j'ai mal prononcé le mot. et alors ?

20
00:02:09.850 -> 00:02:25.049
Philip Sellers : Non, vous savez, c'est vraiment intéressant de venir d'un milieu Vm. Ou d'un arrière-plan. Je l'ai connu quand c'était la simplicité contre la mécanique, vous savez. Les guerres hyperconvergées avant qu'il n'y ait V. Sand.

21
00:02:25.160 -> 00:02:34.150
Philip Sellers : Tout cela. Je suis l'entreprise depuis longtemps et je suis très impressionné par l'écosystème et les services qu'elle propose. C'est pourquoi

22
00:02:34.160 -> 00:02:49.669
Philip Sellers : Je dirais que ce que je vois aujourd'hui, c'est qu'il s'agit vraiment d'un jeu de plateforme, et que l'investissement pour un client est d'investir dans une plateforme qui va lui permettre de fournir les services informatiques dont il a besoin. Et ça, c'est vraiment cool.

23
00:02:49.920 -> 00:02:55.920
Philip Sellers : C'est une valeur sûre. Prop : Lorsque vous commencez à sortir et à parler aux clients de la situation actuelle de Newton.

24
00:02:56.030 -> 00:02:56.750
Oui, c'est vrai.

25
00:02:56.950 -> 00:02:59.750
Andy Whiteside : oui, All on prem Colo.

26
00:02:59.970 -> 00:03:04.010
Andy Whiteside : dans le nuage qui compte, selon vos conditions, là où vous le souhaitez

27
00:03:04.040 -> 00:03:05.420
Andy Whiteside : à tout moment.

28
00:03:06.170 -> 00:03:08.890
Jirah Cox : Je suis heureuse de vous accueillir sur l'antenne.

29
00:03:09.180 -> 00:03:14.939
Andy Whiteside : vous êtes là depuis un certain temps. Vous revenez toujours, vous devez donc vous amuser un peu.

30
00:03:15.190 -> 00:03:16.690
Jirah Cox : Oui, mec. Non, c'est une explosion

31
00:03:16.840 -> 00:03:23.090
Jirah Cox : Vous avez mis en ligne le podcast du partenaire que je suis en train d'enregistrer aujourd'hui.

32
00:03:23.520 -> 00:03:27.110
Philip Sellers : cette semaine, un seul ce mois-ci, j'espère.

33
00:03:27.180 -> 00:03:28.690
Jirah Cox : Oui.

34
00:03:28.860 -> 00:03:36.380
Andy Whiteside : nous apprécions que vous soyez ici, vous validez vraiment ces conversations et vous en tirez beaucoup de bonnes réactions.

35
00:03:37.430 -> 00:03:38.830
Jirah Cox : Oui, c'est amusant à faire

36
00:03:39.310 -> 00:03:44.320
Andy Whiteside : Ben Rogers a été notre client, notre ami sur plusieurs fronts.

37
00:03:44.350 -> 00:03:47.310
Andy Whiteside : fait ce podcast. Ce que vous pensiez qu'il serait.

38
00:03:47.930 -> 00:04:00.920
Ben Rogers : C'est très intéressant, vous savez, quand j'ai fait le podcast sur les agrumes, j'avais 25 ans d'agrumes à mon actif. Je suis donc très confiant, et là où nous sommes allés, c'est un jeu de balle un peu différent, et donc il y a eu quelques fois où je me suis pointé

39
00:04:00.930 -> 00:04:18.250
Ben Rogers : appris à la volée. Vous savez. Ce que j'essaie de faire, c'est de me placer du point de vue du client et de poser des questions. Je pense que les clients voudraient connaître les réponses, mais qu'ils n'osent peut-être pas les poser, ou alors je me penche sur le cas de notre ami le gyro Ninja, et j'essaie d'obtenir un scoop de sa part. Comme je l'ai mis en ligne. Juste

40
00:04:18.260 -> 00:04:36.479
Ben Rogers : le fait d'être près de lui est certainement une grande ressource. Il en a été de même lorsque j'ai pensé que je ne savais pas, je ne sais pas si je savais quoi en penser. Mais je m'amuse. Et à chaque fois que je publie ce podcast, je reçois toujours des commentaires positifs de la part des mécaniciens en tant qu'organisation.

41
00:04:36.490 -> 00:04:48.010
Ben Rogers : et aussi les clients de Newton qui disent qu'ils ont appris X, Y. et Z en écoutant cela. Et Z en écoutant cela. Vous savez, c'est trop poli de dire ça. Je pensais qu'il y avait beaucoup plus de préparation en tant qu'auditeur.

42
00:04:48.110 -> 00:04:57.340
Andy Whiteside : Comme vous, il a dit qu'il avait fait les agrumes avec nous. Il a donc vu l'aile de ce modèle qui produit encore des fruits.

43
00:04:58.760 -> 00:05:10.419
Ben Rogers : D'accord, notre blog est une parenthèse pour ceux qui nous écoutent, vous savez que la philosophie d'Andy sur ces podcasts est d'apprendre le sujet au fur et à mesure que vous vous connectez.

44
00:05:10.430 -> 00:05:24.090
Ben Rogers : au podcast. Nous avons tous environ 2 minutes pour digérer ce dont nous allons parler dans le format expert. Donc pour tous ceux qui sont sur la liste, comprenez simplement que nous sommes assis à la table et que nous avons affaire à cela.

45
00:05:24.650 -> 00:05:33.840
Andy Whiteside : Oui, mais dans ce cas, le blog est le titre du site. J'ai réduit mon cluster de plusieurs nœuds en Rf : 2

46
00:05:33.850 -> 00:05:47.499
Andy Whiteside : par ce qui ressemble à Jerome Dial in serait le nom que j'obtiendrais si j'essayais de prononcer à nouveau ce nom de famille. Je pense que c'est ce que je dirais, et je ne sais pas où j'ai trouvé le " th ", il n'y avait pas de " th ". Je l'ai inventé

47
00:05:47.850 -> 00:05:50.650
Andy Whiteside : Telen, c'est tout à fait logique. Mais

48
00:05:50.700 -> 00:05:56.690
Andy Whiteside : gyro, vous avez apporté ce blog, et heureusement vous avez apporté beaucoup de ces préparations pour en parler.

49
00:05:56.850 -> 00:06:01.110
Andy Whiteside : Quel est l'essentiel de ce qui s'est passé ici, et pourquoi il a écrit cela ?

50
00:06:01.770 -> 00:06:08.479
Jirah Cox : Oui, c'est le cas. J'adore ce billet de Jérôme. Il se trouve sur le blog de notre communauté. D'ailleurs, tout le monde peut devenir membre de la communauté. Et

51
00:06:08.610 -> 00:06:14.100
Jirah Cox : et vous savez, si vous voulez. Si vous avez quelque chose à dire, c'est une excellente plateforme.

52
00:06:14.330 -> 00:06:30.819
Jirah Cox : Jerome a posté ceci à partir de conversations qu'il a eues auparavant, vous savez. Hé, si j'exécute dans ce cas un exemple de 7 nœuds avec Rf. 2, ce qui est notre structure pour maintenir une protection des données en écrivant toutes les données deux fois au sein d'un cluster.

53
00:06:30.970 -> 00:06:37.350
Jirah Cox : Donc ce cluster. Nous disons qu'il peut perdre un élément, un disque ou un nœud. Que se passe-t-il s'il en perd 2 ?

54
00:06:37.380 -> 00:06:48.559
Jirah Cox : C'est vrai ? Et que se passe-t-il dans ce cas ? Dans ce cas, c'est une excellente question, une excellente exploration. Il s'agit ici d'une question très concrète à laquelle nous sommes confrontés et à laquelle nous répondons souvent : nous prévoyons un certain nombre d'échecs. Mais si nous avons plus d'échecs que cela.

55
00:06:49.020 -> 00:06:59.150
Andy Whiteside : Quand il dit dans le deuxième paragraphe, nous avons toujours, quand nous avons des clients plus importants, des grappes de clients. Nous recommandons toujours Rf. 3. Est-ce que c'est juste parce que

56
00:06:59.230 -> 00:07:01.689
Andy Whiteside : plus il y en a, mieux c'est, si l'on dispose de l'espace nécessaire.

57
00:07:02.170 -> 00:07:11.700
Jirah Cox : Oui, et j'ai vu certaines des statistiques, cela se résume à, vous savez, comme n'importe quoi, si vous exécutez même juste comme des choses juste hyperviseur. Seulement

58
00:07:11.770 -> 00:07:17.320
Jirah Cox : si vous pensez à la disponibilité de l'informatique, vous vous dites : "Eh bien, si je fais tourner une grappe de 10 nœuds ou de 100 nœuds...".

59
00:07:17.380 -> 00:07:20.600
Jirah Cox : à un moment donné, je veux aller plus loin que la taille d'un seul.

60
00:07:20.690 -> 00:07:22.879
Jirah Cox : Tout comme je ne ferais pas fonctionner un nœud de 99.

61
00:07:22.910 -> 00:07:28.219
Jirah Cox : cluster de calcul de n'importe quel hyperviseur avec seulement n plus une disponibilité, parce que mes chances en tant qu'utilisateur de l'hyperviseur sont très faibles.

62
00:07:28.250 -> 00:07:33.889
Jirah Cox : son praticien, en tant qu'administrateur ayant plus d'une zone de disponibilité, d'accord, un rayon d'action, appelez-le

63
00:07:34.000 -> 00:07:44.680
Jirah Cox : un seul nœud, un facteur de calcul. en panne à un moment donné. Ces chances augmentent de façon astronomique au-delà d'un certain seuil de comptage. cela dépend toujours. Mais vous savez, en général

64
00:07:45.310 -> 00:08:03.189
Jirah Cox : Allons-y. Permettez-moi de représenter plusieurs points de vue ici. La plupart des Esses vous diraient qu'au moins à ce moment-là, vous atteignez le nœud 24 dans un cluster. Nous sommes probablement à un seuil où nous voulons concevoir ce que nous appelons R 3, c'est-à-dire toutes les données écrites trois fois dans le cluster par rapport à toutes les données écrites deux fois dans un cluster.

65
00:08:03.200 -> 00:08:06.969
Jirah Cox : parce que j'ai des chances qu'un nœud tombe en panne, puis qu'un autre nœud tombe en panne

66
00:08:07.030 -> 00:08:15.830
Jirah Cox : Après cela, je ne peux plus rien faire, ou alors je fais de la maintenance. J'en ai un en panne, puis un autre. Le nœud choisit ce moment pour l'écran violet, ou quoi que ce soit d'autre, et augmente à cette taille.

67
00:08:16.160 -> 00:08:21.669
Andy Whiteside : c'est un peu la logique de ma femme. J'ai 4 voitures, dont la plupart sont vieilles et

68
00:08:22.100 -> 00:08:31.109
Jirah Cox : Plus les voitures sont vieilles, plus il y a de chances. L'une d'entre elles est en panne ? Oui, c'est une analogie fantastique, n'est-ce pas ? Je veux dire, je dis toujours que le matériel va au matériel. Donc

69
00:08:32.330 -> 00:08:33.860
Andy Whiteside : il fera ce qu'il fera.

70
00:08:33.970 -> 00:08:35.090
Harvey Green : Histoire vraie

71
00:08:35.159 -> 00:08:45.099
Andy Whiteside : Très bien. Il obtient donc quelques captures d'écran de son environnement. La première concerne la redondance, le facteur, la préparation avec une catégorie de 2. Les options. Si je devais descendre, la capacité serait la suivante

72
00:08:45.160 -> 00:08:47.860
Andy Whiteside : 2 et 3. Y a-t-il d'autres options ?

73
00:08:48.650 -> 00:09:04.569
Jirah Cox : En gros, c'est vrai pour 99,9, 9 beaucoup de 9 ici, la plupart des charges de travail. Ce sera Rf : 2 et Rf. 3 pour un très petit nombre de charges de travail où vous faites de la redondance dans l'application et où vous avez de la disponibilité. Je pense à une explication, je pense qu'il y en a assez pour faire de la pensée de

74
00:09:04.840 -> 00:09:18.059
Jirah Cox : Quelques charges de travail pour lesquelles l'application va déjà diviser les données et les stocker à deux endroits. Ensuite, bien sûr, vous pouvez faire Rf : One, si quelque chose ne va pas et qu'un disque tombe en panne, ou quoi que ce soit d'autre, il est retiré.

75
00:09:18.110 -> 00:09:18.910
Jirah Cox : Alors

76
00:09:18.940 -> 00:09:30.790
Jirah Cox : vous nous avez dit que vous aviez déjà la disponibilité de l'application un peu ailleurs. C'est vrai ? Nous ne reconstruisons donc pas ces données. Donc, mais oui, pour la plupart, de tous les cas d'utilisation courants de la virtualisation, ce sera Rf : 2 et R. 3.

77
00:09:31.250 -> 00:09:45.979
Andy Whiteside : Je dois faire une petite blague sur moi-même depuis très longtemps. J'ai dit. Rf. pour fréquence droite, et quelqu'un m'a fait remarquer que la fréquence droite commençait par un W. Et je me suis dit, oui, donc, Andy, je pense qu'il y a une chose qui vaut la peine d'être mentionnée ici.

78
00:09:45.990 -> 00:10:05.710
Ben Rogers : et Philip l'a en quelque sorte mentionné dans son introduction. C'est vraiment ce qui crée la plateforme de Newtonics, notre capacité à faire ce Rf. Factor. Non seulement cela nous protège du point de vue de la protection des données. Mais cela entre également en ligne de compte. À quelle vitesse le cluster se rétablit-il ? Vous savez, si nous avons ces données étalées au beurre de cacahuète

79
00:10:05.720 -> 00:10:20.050
Ben Rogers : comme à travers ces nœuds. Si un nœud tombe en panne, un autre nœud peut prendre le relais très rapidement parce qu'il contient les données. Nous avons également beaucoup parlé de Vdi dans votre podcast. Et c'est aussi ce qui fait que notre Bdi contient les données.

80
00:10:20.060 -> 00:10:36.669
Ben Rogers : même si nous répliquons les données, nous gardons la charge de travail locale sur le nœud où se trouvent les données. Et encore une fois, si ce nœud est défaillant, nous avons les métadonnées pour savoir où les récupérer. Vous savez où nous devons aller ensuite pour l'obtenir. Je reviens donc à Phillips.

81
00:10:36.680 -> 00:10:46.930
Ben Rogers : vous savez, il a mentionné qu'il s'agissait d'une plateforme. C'est au cœur de cette plateforme, et c'est vraiment ce qui fait que les nouveaux chars d'assaut disent quand il s'agit de choses comme

82
00:10:47.010 -> 00:10:55.769
Ben Rogers : performance, réplication, désastre, récupération. Ce sont toutes les choses que nous avions sur cette idée de facteur de redondance

83
00:10:57.050 -> 00:11:02.110
Jirah Cox : Tout à fait. Nous vivons à D by Andy. J'allais dire, vous nous connaissez tous les 5 ici, n'est-ce pas ?

84
00:11:02.260 -> 00:11:11.590
Jirah Cox : en tant que technologues dans les Carolines. Nous menons déjà une bataille difficile. C'est vrai ? Merci de ne pas souligner notre mauvaise orthographe en plus de cela, n'est-ce pas ?

85
00:11:12.500 -> 00:11:15.060
Andy Whiteside : Oh, vous devez savoir que je suis allé à l'école primaire.

86
00:11:17.040 -> 00:11:19.749
Jirah Cox : J'ai donc dit que nous étions tous les cinq ici présents et que j'avais ratissé large.

87
00:11:21.360 -> 00:11:27.100
Andy Whiteside : Si vous voulez nous dire ce que signifie l'élément " gestion de Vm : haute disponibilité ".

88
00:11:28.250 -> 00:11:34.529
Philip Sellers : probablement en me regardant comme vous. Tu ne diriges pas l'écran, idiot ! Oui, cette partie

89
00:11:35.520 -> 00:11:37.580
Philip Sellers : Zoom sur le

90
00:11:39.490 -> 00:11:40.810
Philip Sellers : Hé ? Allez-y, John.

91
00:11:41.080 -> 00:11:52.559
Jirah Cox : Bien sûr. La case à cocher est donc l'écran du canal. Est-ce que c'est une réservation ? C'est ça. Donc, en tant que couche de calcul, en tant que virtualisation, en tant que gestion des machines virtuelles, vous pouvez

92
00:11:52.670 -> 00:12:05.920
Jirah Cox : le moteur de haute disponibilité permet d'obtenir deux modèles à la sortie de la boîte. Vous obtenez Ha ! Et vous obtenez le best effort où les Vms impactés par une défaillance matérielle seront redémarrés automatiquement sur les nœuds survivants du cluster.

93
00:12:06.100 -> 00:12:23.940
Jirah Cox : C'est, bien sûr, hors de la boîte Vous obtenez le meilleur effort, et ensuite avec cette case à cocher vous pouvez opter pour hey ? Allez-y et réservez de la mémoire pour moi. Ainsi, la disponibilité de mes faisceaux est déjà garantie. Et pour redémarrer, vous passez d'un modèle de mémoire n plus 0 Vm à un modèle de mémoire.

94
00:12:24.200 -> 00:12:24.890
Andy Whiteside : Oui.

95
00:12:25.520 -> 00:12:38.079
Andy Whiteside : Oui, j'en ai parlé en plaisantant à Philip parce que certaines de ces choses existent depuis un petit moment ou un certain temps et que la plate-forme mécanique, mais lorsque je rencontre des clients, ils supposent que certaines de ces choses ne sont disponibles que du côté de Vmware.

96
00:12:38.130 -> 00:12:39.270
la solution.

97
00:12:39.870 -> 00:12:55.649
Philip Sellers : Oui. Et je veux dire ceci. C'est essentiellement la même chose que Vmware. Il y a donc une parité. Vous savez donc. Ha ! Vous mettez le nombre d'hôtes à échouer, vous savez le niveau de tolérance et dans Vmware, et il réserve cet espace

98
00:12:55.710 -> 00:13:01.810
Philip Sellers : De manière très similaire, bien que ce soit un point de vue légèrement différent, je suppose, du côté de la nouvelle plateforme tenx.

99
00:13:02.180 -> 00:13:16.569
Andy Whiteside : Eh bien, et Phil, si c'est quelque chose que je peux vous demander, venant d'un monde purement Vmware, où maintenant vous faites les deux ? Est-ce que vous avez été surpris par le nombre de fonctionnalités disponibles du côté d'Acropolis qui n'étaient peut-être pas disponibles quand vous l'avez regardé il y a quelque temps, voire jamais.

100
00:13:16.980 -> 00:13:20.249
Philip Sellers : Oh, oui, oui, je le pense vraiment. C'est

101
00:13:20.760 -> 00:13:26.009
Philip Sellers : C'est assez incroyable ce qui a été fait sur la plate-forme, et

102
00:13:26.300 -> 00:13:30.919
Philip Sellers : Il a été activé sur un HP. C'est, vous savez, c'est

103
00:13:32.180 -> 00:13:36.300
Philip Sellers : C'est très comparable si l'on vient d'un DM. Ou d'une formation.

104
00:13:37.690 -> 00:13:46.580
Jirah Cox : Donc c'est. Je veux dire. D'habitude, je dis que c'est différent, mais c'est ça. C'est différent. Il n'y a pas de case à cocher pour chaque case. Box. Vous aviez l'habitude de le voir sur une plateforme, mais il y a tout ce dont vous avez besoin.

105
00:13:48.240 -> 00:13:51.849
Andy Whiteside : Jarra, je vais vous aider à comprendre et à vous laisser faire.

106
00:13:52.240 -> 00:13:57.940
Andy Whiteside : Je passe en revue ce que le client a mis en place et me donne un aperçu, puis je laisserai les autres nous interrompre et...

107
00:13:58.200 -> 00:14:02.939
Andy Whiteside : commentaires si nécessaire. Vous voulez toucher ici où il parle de la charge de travail.

108
00:14:04.190 -> 00:14:11.870
Jirah Cox : Oui. Le drone met donc en évidence qu'il a 30 serveurs virtuels Windows. Ils fonctionnent sous Windows. 11 zoom guy avec btpm activé.

109
00:14:12.160 -> 00:14:14.720
Jirah Cox : Et bien sûr, vous savez que ces systèmes de gestion sont répartis sur l'ensemble du territoire.

110
00:14:14.770 -> 00:14:23.979
Jirah Cox : les nœuds du cluster, c'est ça ? Il y a donc quelques vms qui tournent sur chaque note du cluster, en gros. Qu'est-ce que cela représente ? 4 et demi à peu près ? Vms par message, en moyenne ?

111
00:14:24.470 -> 00:14:30.839
Jirah Cox : Donc si rien n'est Maxed out sur les ressources, il les met en évidence à environ 25%, la consommation de CPU, environ 40% la consommation de mémoire.

112
00:14:32.470 -> 00:14:34.109
Jirah Cox : Alors,

113
00:14:34.710 -> 00:14:37.569
Andy Whiteside : Combien de vdi il y avait. Oh, 30.

114
00:14:37.970 -> 00:14:53.140
Jirah Cox : Non, Yup, ils sont ouais, 30. Oui, 30. Vm : Alors il met son chapeau de singe du chaos et décide d'aller planter un nœud. Il se connecte à la gestion du matériel en dehors de la bande. Il lui dit. Hé, éteignez le serveur immédiatement. Pas d'avertissement

115
00:14:53.150 -> 00:15:01.790
Jirah Cox : pas de notification à la couche de virtualisation. La couche de gestion de la couche de stockage, n'est-ce pas ? Donc, immédiatement, c'est comme si l'on tirait sur le cordon d'alimentation. Un nœud s'éteint.

116
00:15:02.510 -> 00:15:19.359
Jirah Cox : alors, bien sûr, vous ne connaissez pas la surprise. Ce à quoi vous vous attendez. C'est ça ? H. A kicks in vms est redémarré sur les nœuds survivants du cluster, n'est-ce pas ? Donc seul l'impact des vms, bien sûr, doit faire quelque chose de correct. Les autres vms continuent de fonctionner. Les nœuds restants sont donc alimentés en électricité.

117
00:15:19.560 -> 00:15:34.199
Jirah Cox : Le tableau de bord de la prison droite. Nous donnons beaucoup de pixels sur le tableau de bord pour montrer à l'administrateur le cluster, l'état et ce qui se passe, n'est-ce pas ? Quelles sont les opérations que nous effectuons ? Qu'est-ce que nous sommes en train de récupérer ? Ou est-ce que tout est totalement normal ? Donc, immédiatement, il montre qu'il entre dans un état de guérison.

118
00:15:34.210 -> 00:15:39.750
Jirah Cox : Il s'agit d'alertes indiquant que les serveurs hey sont en cours de migration ou de redémarrage afin de revenir à un état de haute disponibilité.

119
00:15:40.210 -> 00:15:56.500
Jirah Cox : et puis, bien sûr, la reconstruction du stockage se produit également, n'est-ce pas ? Donc, lorsque vous perdez l'instance matérielle, n'est-ce pas ? L'instance de l'hyperviseur, vous allez perdre une partie de tous vos Vm utilisateurs. Vos Vms de provision client : et puis, bien sûr, notre machine virtuelle aussi, n'est-ce pas ? Notre Cvm. Notre Vm contrôleur.

120
00:15:56.510 -> 00:16:00.250
Jirah Cox : Nous en exécutons donc un sur notre cluster renouvelable, de sorte que Cbm. diminue également.

121
00:16:00.810 -> 00:16:07.810
Jirah Cox : En effet. Il hébergeait une partie des données en gros. Dans ce cas, un septième de toutes les données stockées dans le cluster.

122
00:16:08.020 -> 00:16:16.989
Jirah Cox : Et donc les 6 autres Cbms survivants vont commencer cette reconstruction pour reprendre la sélection du nœud défaillant, et donc le Cvm défaillant. De même.

123
00:16:17.820 -> 00:16:23.390
Andy Whiteside : Donc Gyra n'a pas dit ou n'a pas dit s'il s'agissait d'une maladie persistante ou non persistante. Vdi

124
00:16:24.670 -> 00:16:28.620
Jirah Cox : Bonne question, ce n'est pas dit, et laissez-moi réfléchir si cela a de l'importance.

125
00:16:28.680 -> 00:16:30.880
Jirah Cox : vraiment

126
00:16:31.060 -> 00:16:39.629
Jirah Cox : Non, n'est-ce pas ? Parce que si ce n'est pas persistant. Vous allez revenir à cette image vierge. C'était ce que vous savez, l'état de congélation du maître de l'or.

127
00:16:39.860 -> 00:16:46.409
Jirah Cox : S'il est persistant, il s'agit simplement d'un événement de mise hors tension sur un autre nœud.

128
00:16:46.750 -> 00:17:02.180
Philip Sellers : Il faudra peut-être un peu plus de temps pour saisir tous les éléments d'un cas non persistant, parce qu'il y en a probablement plus. Le processus de guérison sera donc peut-être un peu plus long. Mais peut-être, mais pour poursuivre la tangente, si vous utilisez du non persistant avec nous, vous ferez probablement du

129
00:17:02.360 -> 00:17:05.090
Jirah Cox : Eh bien. Si vous faites du Pvs correctement, alors quel que soit le réseau

130
00:17:05.270 -> 00:17:16.910
Jirah Cox : c'est le réseau. Si vous faites du Mcs correctement, alors vous faites des différences de disques par rapport à un snapshot Goldmaster, et nous sommes en fait sous les couvertures. Nous ferons ce que nous appelons un clone d'ombre.

131
00:17:16.980 -> 00:17:24.189
Jirah Cox : où, chaque fois que nous détectons qu'il y a un disque V dans le cluster. C'est une tâche supplémentaire, n'est-ce pas ? C'est un disque V qui alimente plusieurs vms.

132
00:17:24.250 -> 00:17:26.530
Jirah Cox : En fait, nous allons cacher que le

133
00:17:26.609 -> 00:17:44.220
Jirah Cox : localement sur chaque nœud du cluster, de sorte que toutes ces lectures reviennent à la mémoire flash locale. Nous interceptons cette opération de lecture depuis l'hyperviseur jusqu'au disque V, et nous la lançons localement, même si l'autorité de copie se trouve ailleurs dans le cluster. Nous raccourcissons donc le chemin de lecture. Vous ne le sentirez pas vraiment, je ne pense pas.

134
00:17:44.840 -> 00:17:45.610
Philip Sellers : Oui.

135
00:17:45.900 -> 00:17:55.769
Andy Whiteside : Alors, Harvey. Je ne suis pas. Je n'ai pas le droit de dire que si vous ne faites pas de persistance, et que vous utilisez Mcs ou Dsa Pvs. Cette case à cocher où vous êtes en relation avec la réservation de matériel

136
00:17:55.830 -> 00:17:59.940
Andy Whiteside : cela n'arrivera probablement pas parce qu'il faut retirer les machines pour couvrir cela.

137
00:17:59.990 -> 00:18:11.940
Harvey Green : Oui, vous n'avez pas besoin d'avoir cette réservation supplémentaire parce que vous avez un pool, et ce n'est pas grave si vous les perdez si vous en redémarrez d'autres. L'utilisateur peut

138
00:18:12.230 -> 00:18:15.100
Harvey Green : perdent leur session.

139
00:18:15.480 -> 00:18:19.760
Harvey Green : pendant une minute. Mais ils peuvent ensuite en redémarrer un autre.

140
00:18:20.040 -> 00:18:21.430
Jirah Cox : Oui, il y a

141
00:18:21.510 -> 00:18:29.729
Jirah Cox : Vous parlez d'un modèle où l'on fait du " one to many ", n'est-ce pas ? Vous avez beaucoup d'utilisateurs par vm. L'instance n'est pas un modèle un à un.

142
00:18:30.110 -> 00:18:35.370
Andy Whiteside : Il peut s'agir d'une à une des machines qui fonctionnent en permanence. Disons qu'il en a 30.

143
00:18:35.390 -> 00:18:42.680
Andy Whiteside : La vérité est qu'il avait 22 ou peut-être 30 utilisateurs. Il en aurait probablement 35 ou 40 en activité, donc il aurait probablement perdu.

144
00:18:42.820 -> 00:18:46.390
Andy Whiteside : Vous savez, certains utilisateurs seraient revenus et auraient eu plus de machines.

145
00:18:46.430 -> 00:18:57.820
Andy Whiteside : l'hyperviseur, pas l'hyperviseur, mais le plan de contrôle aurait reconnu. Hé, je suis. Je suis censé avoir 10 machines qui tournent et qui attendent. Il s'est passé quelque chose. Je n'en ai plus que 9 ou 5, ou je ne sais quoi, j'ai besoin d'en allumer plusieurs, ou je ne sais quoi encore.

146
00:18:58.250 -> 00:18:58.940
Jirah Cox : Hmm.

147
00:18:59.930 -> 00:19:06.110
Andy Whiteside : Les chances sont donc bonnes. Le consultant ne cocherait jamais cette case si elle n'était pas persistante. Mais qui sait ? Je ne connais pas la situation.

148
00:19:08.080 -> 00:19:13.079
Andy Whiteside : De toute façon ? d'accord. Donc la reconstruction et ensuite, Gyro, peut-être que je suis ici

149
00:19:13.780 -> 00:19:19.240
Andy Whiteside : suis-je là où il est écrit, données, résilience, statut ou non. Oui. Donc, la reconstruction

150
00:19:19.360 -> 00:19:27.380
Jirah Cox : Il continue. Et cela se voit immédiatement. Cela montre, vous savez, mon cluster, qui est construit pour perdre un seul élément à la fois.

151
00:19:27.430 -> 00:19:46.580
Jirah Cox : qu'il s'agisse d'un disque ou d'une note, ou autre. Donc, sur le tableau de bord, n'est-ce pas ? Ils vont afficher le défaut. La tolérance est de 0, n'est-ce pas ? On a un petit drapeau rouge à côté. Vous pouvez cliquer dessus, et même vous donner une vue détaillée de ce qui est en train d'être reconstruit. Et vous connaissez le cluster Newtonics, n'est-ce pas ? Et vraiment ce que le Cdm fait pour vous tous les jours, tous les jours.

152
00:19:46.590 -> 00:20:00.499
Jirah Cox : Il ne s'agit pas d'une application monolithique géante, n'est-ce pas ? Comme Cdm. Ou d'aos. Il s'agit d'un ensemble de micro-services au sein du cluster qui fonctionnent tous ensemble, n'est-ce pas ? Je vais créer le cluster ou la topologie en anneau.

153
00:20:00.620 -> 00:20:13.369
Jirah Cox : Chacun d'entre eux peut élire lui-même les différents états du leader, du leader et du suiveur, et la capture d'écran vous montre la partie correspondante. Ici, il s'agit de l'anneau Cassandra lui-même. La partition des métadonnées, c'est ça ? C'est là que nous stockons nos données sur les clients.

154
00:20:13.380 -> 00:20:26.859
Andy Whiteside : dans la grappe. C'est la couche qui se reconstruit dans ce cas, pour revenir à la résilience, à la santé. Jusqu'à ce qu'il puisse en perdre un autre. N'importe quoi, n'est-ce pas ? Un membre dans ce cercle. Revenons-y. Rf : ce Rf : 2 stade où il est couvert par la loi.

155
00:20:27.160 -> 00:20:37.099
Jirah Cox : On peut considérer qu'il s'agit de revenir à Rf. Pour un certain nombre de mesures, n'est-ce pas ? Rf : 2 pour les données de l'utilisateur, Rf : 2 pour les données de détection du cluster lui-même.

156
00:20:38.100 -> 00:20:39.010
Andy Whiteside : et

157
00:20:39.260 -> 00:20:42.299
Andy Whiteside : Terra. Que se passe-t-il si c'est le cas ? S'il n'y a pas assez de

158
00:20:42.650 -> 00:20:44.190
Andy Whiteside : l'espace.

159
00:20:44.220 -> 00:20:46.469
Andy Whiteside : ou je suppose qu'ils vous l'auraient dit avant que cela n'arrive.

160
00:20:47.320 -> 00:20:56.609
Jirah Cox : Je veux dire que cela fait partie de la planification, car nous ne voulons jamais qu'un client se trouve dans une situation où il ne pourrait pas perdre sa disponibilité définie.

161
00:20:56.820 -> 00:21:01.940
Jirah Cox : seuil, comme dans notre 2 cluster. C'est vrai qu'on peut faire n'importe quoi

162
00:21:02.050 -> 00:21:12.199
Jirah Cox : ce qui inclut un nœud ? Nous ne voulons pas que vous soyez à moins d'un nœud de remplir le cluster si vous le faites. Et alors, oui, tout à fait, la question va se remplir Vous allez passer une mauvaise journée.

163
00:21:12.210 -> 00:21:24.749
Jirah Cox : En réalité, si vous remplissez un espace, il va passer en lecture seule pour se protéger et produire vos données pour dire que je ne vais pas refuser de nouveaux droits parce que nous sommes juste pleins,

164
00:21:24.940 -> 00:21:29.099
Jirah Cox : vous savez. Appelez le service d'assistance. Il faut qu'on répare ça ou qu'on appelle, vous savez.

165
00:21:29.350 -> 00:21:35.680
Jirah Cox : Appel ban appel Harvey bon appel, Phil. Nous avons besoin de plus d'espace ici, alors vous savez, de plus grands disques, d'autres nœuds, tout ce qu'il faut pour

166
00:21:35.960 -> 00:21:44.599
Jirah Cox : pour établir l'état de santé du cluster. Souvent, il peut s'agir de supprimer de vieux snapshots si vous le souhaitez. Mais oui, si vous n'avez plus d'espace pour toujours, il va juste passer en lecture seule

167
00:21:45.690 -> 00:21:51.619
Andy Whiteside : Permettez-moi de faire une pause, Ben Harvey, Philip, des questions, des commentaires, des idées à retenir.

168
00:21:53.790 -> 00:21:57.559
Harvey Green : non, je veux dire, je pense que c'est

169
00:21:58.040 -> 00:22:06.739
Harvey Green : Vous décrivez clairement l'endroit où vous serez, vous appelez Phil et il arrive avec toutes sortes de disques dans sa poche arrière. Il peut les échanger pour vous.

170
00:22:06.790 -> 00:22:12.700
Jirah Cox : Il suffit de se rendre au magasin Best Buy et d'aspirer quelques disques.

171
00:22:16.000 -> 00:22:33.739
Ben Rogers : Eh bien, je veux dire que l'une des choses que nous devons souligner, c'est qu'avant même que vous ne soyez dans cet état. La grappe serait en train d'analyser le meurtre sanglant. Il serait en train de faire. Hey ? Je ne peux pas. Je ne peux pas exécuter notre F 2. Je ne suis pas en mesure d'atteindre cet état de conformité qui nécessite plus de mémoire. Nous devons planifier la capacité du cluster. Nous devons planifier la capacité du cluster.

172
00:22:33.750 -> 00:22:47.499
Ben Rogers : même si je sais que nous sommes en quelque sorte dans le laboratoire et que nous faisons cela. Nous ne verrons pas les résultats. Je ne veux pas que nos clients pensent cela. Oh, il n'y a pas d'avertissement que cela va arriver dans ces boîtes où ces choses se retrouvent dans un état malsain de l'ONU.

173
00:22:47.870 -> 00:22:56.920
Jirah Cox : Tout à fait. Mais oui, le cluster lui-même. Nous lui avons appris de nombreux trucs au fil des ans. Il vous enverra un courrier électronique. Il peut envoyer des alertes Snmp. Il peut ouvrir un service maintenant. Tickets, si vous l'autorisez.

174
00:22:57.000 -> 00:23:04.819
Jirah Cox : Des tas de trucs amusants. Il doit vous alerter, hé ? Nous entrons dans un, vous savez, seuil non résilient à droite de l'état de la grappe. seuil non résilient à droite de l'état de cluster ici.

175
00:23:04.950 -> 00:23:15.170
Jirah Cox : si vous voulez, si vous autorisez la télémétrie par téléphone à la maison, c'est ça ? Nous l'appelons " pulse ", n'est-ce pas ? Nous pouvons donc téléphoner à la maison pour savoir si le cluster que vous utilisez est en bonne santé, et il peut envoyer un signal à votre équipe de gestion des comptes, n'est-ce pas ? Ils vous contacteront

176
00:23:15.300 -> 00:23:26.230
Jirah Cox : C'est possible. Il y a une nouvelle astuce que les clusters ont apprise l'année dernière et qui consiste à dire que dans ce cas, disons que vous avez un cluster de 7 nœuds. Il ne faut donc pas écrire plus de 6 nœuds de données.

177
00:23:26.630 -> 00:23:30.530
Jirah Cox : Vous pouvez lui dire de ne me montrer que 6 tonnes de données.

178
00:23:30.590 -> 00:23:43.749
Jirah Cox : et ne prétendez même pas que le septième nœud existe. C'est-à-dire qu'un 100% est la ligne à 6 nœuds. Redessinez tous les graphiques pour dire voici à quoi ressemble le plein. C'est ce qui, si nous sommes en bonne santé, se trouve quelque part à gauche de cette ligne.

179
00:23:43.780 -> 00:23:48.260
Jirah Cox : Ne m'obligez pas à suivre. Suis-je au-dessus ou au-dessous de mon seuil de 6 nœuds ?

180
00:23:48.860 -> 00:23:49.600
droit

181
00:23:50.500 -> 00:24:01.430
Andy Whiteside : donc le bocal avec les sections suivantes est après 30 minutes. Cbm. Non joignable pendant 30 minutes. Le nœud est en train d'être détaché. En d'autres termes, cela signifie que je vais complètement retirer ce type de mon stockage.

182
00:24:01.870 -> 00:24:04.790
Jirah Cox : Oui. C'est ce que j'aime beaucoup. Nous avons déjà

183
00:24:04.910 -> 00:24:09.249
Jirah Cox : a entamé le processus. À ce stade, nous sommes probablement déjà sur le point d'achever le processus de

184
00:24:09.270 -> 00:24:11.769
Jirah Cox : guérir de l'échec de l'État

185
00:24:11.890 -> 00:24:16.290
Jirah Cox : Ce que j'aime chez les mutants et dans le design des clusters en général, c'est l'autoguérison.

186
00:24:16.320 -> 00:24:24.890
Jirah Cox : Ainsi, nous ne restons pas très longtemps dans un état de 7 nœuds cassés, nous passons à un état de 6 nœuds sains. 6 nœuds devient la nouvelle norme.

187
00:24:24.960 -> 00:24:36.420
Jirah Cox : Il s'agit de tous les nœuds du cluster et de tous les nœuds que nous connaissons. Nous ne restons donc pas dans un état dégradé. Nous éjectons la septième note qui a échoué de l'anneau de métadonnées à partir de notre connaissance des nœuds existant dans le cluster.

188
00:24:36.510 -> 00:24:43.130
Jirah Cox : Pour de nombreuses raisons, la bonne étant que nous l'oublions. Il y a des choses que nous pouvons nettoyer, nous n'attendons pas qu'il revienne en ligne.

189
00:24:43.760 -> 00:24:46.550
Jirah Cox : Encore un, n'est-ce pas ? Disons que cette note est en panne pendant une semaine

190
00:24:46.720 -> 00:24:48.210
Jirah Cox : dans une semaine. Lorsque la question sera abordée

191
00:24:48.330 -> 00:24:50.090
Jirah Cox : il ne contient pratiquement aucune donnée utile.

192
00:24:50.190 -> 00:25:04.420
Jirah Cox : Nous ne voulons donc pas le traiter comme s'il s'agissait d'un nœud prodigue qui revient à la maison, n'est-ce pas ? Nous le lirons comme s'il s'agissait d'un nouveau nœud et que les données de la refonte s'y appliquaient plutôt que par des différences du type : " Oh, qu'y a-t-il de nouveau ? Oh, qu'est-ce qui est nouveau ? Qu'est-ce qui a changé ? Ce qui n'a pas changé.

193
00:25:04.430 -> 00:25:16.889
Jirah Cox : Nous allons simplement couper l'appât, et ensuite, s'il revient en pleine forme, nous le ferons. Nous l'accepterons à nouveau dans le cluster en tant que nouveau nœud, en prenant la place du nœud 7, sans avoir à nous soucier des différences. Quelles sont les données qui ont changé ou qui n'ont pas changé ?

194
00:25:17.620 -> 00:25:21.220
Andy Whiteside : nous guérissons toujours, nous guérissons toujours jusqu'à ce que nous soyons en bonne santé. Nous ne

195
00:25:21.250 -> 00:25:23.860
Jirah Cox : rester dans un état dégradé chaque fois que cela est possible.

196
00:25:24.050 -> 00:25:27.409
Andy Whiteside : Oui, cela vous permet de dormir la nuit, sans avoir à deviner ce que vous allez faire.

197
00:25:27.630 -> 00:25:46.130
Ben Rogers : cela pourrait se produire quand on n'est pas là pour le voir. Les gars, des commentaires à ce sujet ? En ce qui me concerne, cela me rassurerait, car il m'est arrivé plusieurs fois de quitter le bureau. Il m'est arrivé plusieurs fois de quitter le bureau et de constater qu'un lecteur, dont on sait qu'il a un R. 5, tombe en panne alors qu'on est en train de le récupérer. La merde vous revient

198
00:25:46.140 -> 00:25:54.690
Ben Rogers : ces quelques heures. Vous ne faites que prier. Les guides qui ne laissent rien aller de travers. Je veux dire par là que

199
00:25:54.700 -> 00:26:19.929
Ben Rogers : Pour moi, savoir que ma technologie s'auto-guérit et supposer que... Oh, les unités sont mauvaises. Nous allons aller de l'avant et le sortir. Le mélange. Nous allons continuer à fonctionner dans un état sain, et vous voulez ramener cette unité, c'est très bien. Mais nous allons la traiter comme une nouvelle unité. C'est génial. C'est vraiment rassurant de ne pas avoir à, vous savez, s'asseoir sur des aiguilles. d'être dans l'expectative. On vous expédie des choses, on vous les procure, ou tout ce que nous avons l'habitude de faire.

200
00:26:20.820 -> 00:26:21.570
Non.

201
00:26:21.940 -> 00:26:30.079
Andy Whiteside : Jerome a donc fait un pas de plus, je crois, et il est maintenant prêt à savoir qu'il peut faire tomber un autre nœud et continuer à fonctionner.

202
00:26:30.410 -> 00:26:47.650
Jirah Cox : Oui. Le processus reste donc le même. Vous pouvez donc continuer à planter un nœud aussi longtemps que vous le souhaitez. Vous pouvez en planter un à la fois. Tant que vous laissez le temps à la guérison de se terminer, et entre chaque défaillance de nœud, vous pouvez passer de 7 à 6, de 6 à 5, de 5 à 4

203
00:26:48.660 -> 00:27:02.540
Jirah Cox : pour descendre à 3, et il parle en fait de, vous savez quoi si vous continuez jusqu'à ce qu'il ne vous reste plus que 2 nœuds, 2 nœuds à ce moment-là. nous le faisons sous les couvertures, n'est-ce pas ? Nous avons un mandat pour sonner. C'est-à-dire 3 nœuds à une taille minimale pour Rf : 2.

204
00:27:02.550 -> 00:27:21.860
Jirah Cox : C'est à peu près ce qu'il y a de plus raté, c'est-à-dire que vous pourriez avoir un cluster de 3 nœuds. Et puis zut ! Un nœud de plus, et il ne reste plus que 2 nœuds sur 3, 1, 2 pieds sur 3 sur le tabouret. Celui-là ne se rétablira pas parce qu'on ne peut pas réduire à un cluster sain de 2 nœuds à partir d'un cluster plus grand de 7 nœuds.

205
00:27:21.870 -> 00:27:32.430
Jirah Cox : 3. Non. Le minimum est là. Donc, une fois que vous avez atteint ce seuil de nœuds libres et que vous perdez un nœud de plus, vous pouvez fonctionner. Vous pouvez certainement atteindre Rf : 2 pour les données des clients, n'est-ce pas ? Toutes vos données sont écrites deux fois. Dans ce cas, c'est

206
00:27:32.450 -> 00:27:37.790
Jirah Cox : Entièrement en miroir, c'est vrai. Tout est sur le nœud 1 et le nœud 2, et le nœud 3 est en panne. Pensez

207
00:27:38.380 -> 00:27:58.159
Jirah Cox : à ce moment-là. Si vous perdez un nœud de plus, c'est fini. Vous n'avez plus de cluster, vous n'avez plus qu'un nœud sur 7. C'est une situation de non survie pour les données. Vos données sont en sécurité, mais elles ne vont pas fonctionner, elles ne vont pas être opérationnelles, elles ne vont pas être un état en ligne pour le cluster. et à ce moment-là, vous devez aller chercher des pièces de rechange et mettre en ligne au moins un autre nœud de votre cluster.

208
00:27:58.170 -> 00:27:59.770
Jirah Cox : un nœud sur 7 États

209
00:28:00.660 -> 00:28:03.659
Andy Whiteside : Et Tyra. Est-ce que tout cela était faisable

210
00:28:03.880 -> 00:28:06.599
Andy Whiteside : à cause de Oui, la magie de la Newtonique, plus

211
00:28:06.810 -> 00:28:10.190
Andy Whiteside : le fait qu'il fonctionnait avec une capacité si faible au départ.

212
00:28:10.820 -> 00:28:16.049
Jirah Cox : Tout à fait, c'est donc la limite réelle que la plupart des clients atteindront en premier lieu, à moins que vous n'utilisiez que ce que vous voulez.

213
00:28:16.260 -> 00:28:19.869
Jirah Cox : un simple calcul nous le dirait. Un septième de votre capacité de stockage.

214
00:28:20.010 -> 00:28:29.290
Jirah Cox : Vous rencontrerez d'abord ce problème, disons que vous utilisez 3 nœuds de stockage. Ensuite, dès que vous devez reconstruire sur moins de 3 nœuds, les données ne tiennent plus.

215
00:28:29.400 -> 00:28:31.890
Jirah Cox : Nous allons dire que ce groupe est complet.

216
00:28:32.190 -> 00:28:38.879
Jirah Cox : Il va passer en lecture seule. Et à ce moment-là, il faut certainement faire quelque chose. Mettre la main sur le matériel défaillant et le remettre en ligne.

217
00:28:39.020 -> 00:28:39.720
Oui, c'est vrai.

218
00:28:39.760 -> 00:28:40.470
d'accord.

219
00:28:41.200 -> 00:28:59.130
Jirah Cox : Mais oui, c'est possible. Vous pouvez faire échouer le nez jusqu'au niveau de l'eau de la grappe. C'est ça ? Si la grappe représente un certain seau, vous pouvez perdre le haut du seau et une autre partie du seau. Vous pouvez continuer à le perdre jusqu'à ce qu'il soit plein, et une fois que vous avez atteint ce seuil, il se remplit et nous passons en lecture seule à cette date.

220
00:29:00.370 -> 00:29:18.619
Andy Whiteside : et ensuite de le remettre en ligne. Il suffit d'ajouter un nœud, un nœud, un nœud au fur et à mesure qu'ils deviennent sains et que vous voulez les réintroduire. Ils arrivent comme un corps étranger. On dirait, n'est-ce pas ? Tout à fait. Oui. Donc il y a un clic sur une prison pour dire, ouais, comme, Admettre ce noeud dans le cluster.

221
00:29:18.630 -> 00:29:29.290
Jirah Cox : Si vous n'êtes pas sûr de vous, comme nous. Nous avons en quelque sorte une couche logicielle. Nous avons un peu de méfiance, je pense, une méfiance sage et plutôt saine à l'égard de la santé du matériel.

222
00:29:29.390 -> 00:29:36.329
Jirah Cox : Donc, si cette note s'est envolée, elle est montée et descendue, elle a causé suffisamment d'aigreurs d'estomac pour qu'on l'éjecte du ring.

223
00:29:36.730 -> 00:29:55.410
Jirah Cox : Nous allons vous obliger à nous le dire. Faites confiance à cette note encore une fois plutôt que de le faire pleinement, de manière proactive, n'est-ce pas ? Peut-être que vous testez quelque chose, vous savez. Nous vous laisserons nous dire quand la tempête sera passée, et alors nous admettrons à nouveau ce nœud dans le centre de données. Nous admettrons ce nœud dans le ring.

224
00:29:57.090 -> 00:30:01.619
Jirah Cox : Il y a donc des choses auxquelles nous pensons. Il y a des choses que nous ne pouvons pas déterminer de manière programmatique en tant que logiciel uniquement

225
00:30:02.160 -> 00:30:11.160
Andy Whiteside : mit ctl. Dans une large mesure, il est donc conscient de l'existence de ce nœud et de la possibilité qu'il soit mis en ligne. Mais il l'a complètement atténué pour l'instant jusqu'à ce que vous lui disiez, hey ? Je suis prêt à ce que vous reconsidériez la question 150

226
00:30:11.940 -> 00:30:13.299
Andy Whiteside : faire revenir ce type.

227
00:30:13.940 -> 00:30:15.419
Jirah Cox : Oui, c'est juste.

228
00:30:15.830 -> 00:30:16.500
D'accord.

229
00:30:17.320 -> 00:30:19.360
Andy Whiteside : Philip, je vous donne la parole en premier.

230
00:30:19.590 -> 00:30:23.740
Andy Whiteside : Avez-vous d'autres questions, commentaires, réflexions, choses à ajouter ?

231
00:30:23.810 -> 00:30:29.270
Philip Sellers : Oui, je voulais poser une question sur le temps d'exposition. Vous savez, nous avons cette durée de 30 minutes...

232
00:30:29.400 -> 00:30:36.170
Philip Sellers : temps mort avec le Cvm. Lorsqu'il est éjecté de l'anneau de métadonnées. Donc

233
00:30:36.690 -> 00:30:44.140
Philip Sellers : vous. Vous êtes en quelque sorte assis dans un état d'exposition, de temps ou d'exposition pendant ces 30 minutes ou plus.

234
00:30:44.380 -> 00:30:49.550
Philip Sellers : 30 minutes, plus le temps nécessaire pour poursuivre la reconstruction. N'est-ce pas ?

235
00:30:49.630 -> 00:30:52.400
Jirah Cox : C'est une question fantastique. En fait, croyez-le ou non. Vous n'avez pas

236
00:30:52.480 -> 00:30:57.360
Jirah Cox : donc dès que le nœud tombe en panne à la seconde suivante

237
00:30:57.470 -> 00:31:00.679
Jirah Cox : Nous commençons immédiatement à reconstruire les données des clients.

238
00:31:00.920 -> 00:31:08.479
Jirah Cox : et chaque nouveau droit également. Donc si le Vm. génère une nouvelle donnée sur, disons, au début des 6 nœuds survivants dans le cluster.

239
00:31:08.550 -> 00:31:16.470
Jirah Cox : Nous honorons immédiatement ce droit sur deux nœuds différents. N'est-ce pas ? Peut-être qu'il devait initialement être ciblé sur le nœud 1 et le nœud 7 pour les deux copies répliquées.

240
00:31:16.510 -> 00:31:28.649
Jirah Cox : Mais maintenant, ce sera nœud, un et nœud 6 ou nœud, un et nœud 5, ou quoi que ce soit d'autre, donc nous n'accepterons jamais d'écrire en tant que plate-forme. Nous ne le ferons jamais. C'est à la droite du Vm. Nous ne pouvons pas respecter le facteur de réplique, n'est-ce pas ? Rf : 2 ou Rf. 3.

241
00:31:29.080 -> 00:31:39.450
Jirah Cox : Ainsi, chaque donnée est immédiatement corrigée, prédite de cette façon pour les nouvelles données, et nous obtenons immédiatement la reconstruction des données des clients. En fait, c'est comme ça. Disons simplement que ce scénario de crédit est hypothétique.

242
00:31:39.490 -> 00:31:50.460
Jirah Cox : Les nouveaux droits sont immédiatement protégés en fonction du facteur de réplique, et disons que la reconstruction se termine dans 15 minutes. Les 15 minutes restantes correspondent simplement à notre confiance dans la note elle-même.

243
00:31:50.480 -> 00:31:58.840
Jirah Cox : avant de l'éjecter de la minute ou de l'anneau. mais ce n'est pas vraiment en contact avec l'utilisateur cela n'expose pas, ne risque pas ou ne cause pas d'exposition à votre point de vue, mon ami. Excellente question. Excellente question.

244
00:31:58.870 -> 00:32:17.419
Philip Sellers : Et c'est tout à fait logique, car tant que la reconstruction est en place, tous les éléments sont protégés. C'est vrai. Oui, c'est vrai. C'est vrai. Il y a donc des parties de ce projet qui relèvent totalement du baseball interne, sous les couvertures, sous le capot. Je dois dire que nous sommes très transparents sur ce qui se passe, et tout cela se trouve également dans la Bible de la mécanique. C'est vrai ?

245
00:32:17.430 -> 00:32:30.989
Jirah Cox : en termes de quoi ? Quelles couches de données alimentent le système et contribuent à la disponibilité. mais oui, cela a toujours été un fonctionnement. La thèse est, vous savez, que nous devons être absolument paranoïaques à propos des

246
00:32:31.000 -> 00:32:43.470
Jirah Cox : l'intégrité des données des clients, n'est-ce pas ? Sinon, nous sommes tout simplement inutiles en tant que plateforme, n'est-ce pas ? Personne ne devrait nous faire confiance. Cela a donc toujours été le travail. La première est d'être un bon gestionnaire des données des clients, et cela inclut une reconstruction immédiate sans délai jusqu'à ce que nous commencions la reconstruction. Nous ne le faisons jamais.

247
00:32:43.520 -> 00:33:00.409
Jirah Cox : Nous ne supposons jamais que le matériel va revenir en bon état. Nous ne retarderons donc jamais la reconstruction, en espérant qu'elle se fera, pour nous faciliter la vie. Nous prenons le chemin le plus difficile, celui de la reconstruction immédiate. Et dans le pire des cas, si le matériel ne revient pas parce qu'il s'agit simplement d'une panne de courant transitoire ou d'un redémarrage.

248
00:33:00.480 -> 00:33:11.259
Jirah Cox : Eh bien, dans le pire des cas, nous avons dépassé, prédit certaines données, et nous pouvons faire ce nettoyage des ordures, n'est-ce pas ? Mais nous ne le ferons jamais. Nous ne laisserons jamais le client s'exposer en espérant et en priant pour que le matériel revienne alors qu'il pourrait ne pas revenir.

249
00:33:12.140 -> 00:33:17.899
Philip Sellers : Oui, l'autre chose. Et juste pour réitérer ce que vous avez dit, vous savez que vous avez

250
00:33:18.370 -> 00:33:33.199
Philip Sellers : Ce concept de cache local dans chaque nœud, et avec Vdi, c'est l'une des choses qui en font vraiment une grande plateforme pour l'exécution. Vdi a cette copie locale sur chacun de vos nœuds. Donc, surtout les bureaux non persistants.

251
00:33:33.370 -> 00:33:35.280
Philip Sellers : Ils sont là.

252
00:33:35.510 -> 00:33:44.679
Philip Sellers : Vous savez, ce n'est jamais plus rapide que cela. C'est vrai. C'est difficile. Il dit que vous n'obtiendrez jamais de la nourriture plus rapidement que dans votre propre cuisine. Il dit que vous n'obtiendrez jamais de la nourriture plus rapidement que dans votre propre cuisine.

253
00:33:45.110 -> 00:33:49.220
Philip Sellers : C'est l'un de ces grands compromis entre les plateformes, et et...

254
00:33:49.310 -> 00:34:03.790
Philip Sellers : Vous l'avez déjà dit. Mais vous savez, je voulais juste le réitérer, le souligner à nouveau parce que c'est l'un des meilleurs cas d'utilisation et la raison pour laquelle nous aimons le faire. L'IDV sur les nouveaux réservoirs est architecturale. Il y a des choses qui nous aident.

255
00:34:05.950 -> 00:34:18.300
Andy Whiteside : Oui, il y a des choses que nous voulions depuis toujours. Il a suffi que de nouveaux réservoirs apparaissent pour que cela soit traité à un niveau inférieur à la surface, pour que nous puissions nous occuper des connexions et des

256
00:34:18.750 -> 00:34:20.830
Andy Whiteside : l'utilisateur habilitant ? L'expérience.

257
00:34:22.960 -> 00:34:25.689
Ben Rogers : Vous savez ce qu'est le meilleur

258
00:34:26.790 -> 00:34:39.430
Ben Rogers : la meilleure chose à propos de. Hv : Eh bien, l'un d'entre eux est le coût de l'inclusion. Mais non, qu'est-ce que vous mettez en évidence.

259
00:34:39.550 -> 00:34:44.779
Ben Rogers : Vous savez, nous sommes des clients, vous savez. Oublions tout ce qui concerne la prolongation et tout le reste

260
00:34:44.810 -> 00:35:00.130
Ben Rogers : nous entrons dans. Vous savez, une petite récession. Le temps va être un peu compté. Beaucoup de clients sont à l'affût. C'est un moyen. Est-ce que je peux alléger mon budget et utiliser quelque chose que je possède déjà plutôt que d'essayer de réinventer la volonté avec un produit secondaire.

261
00:35:02.120 -> 00:35:12.999
Andy Whiteside : Oui, je comprends tout à fait. Je suis tout à fait d'accord, je veux dire qu'au début, c'était un argument qui était vrai, mais qui n'était pas évident. Mais comme Philip l'a souligné il y a un moment, cette chose que vous avez

262
00:35:13.190 -> 00:35:24.020
Andy Whiteside : vous avez créé cette plate-forme rentable à laquelle ont été ajoutés tous ces services supplémentaires. Ce n'est pas gratuit

263
00:35:24.100 -> 00:35:29.539
Ben Rogers : maintenant. Personne ne l'obtient gratuitement, mais il est inclus dans votre licence Als.

264
00:35:30.130 -> 00:35:30.770
n'est-ce pas ?

265
00:35:31.290 -> 00:35:34.720
Jirah Cox : Tout à fait. Tout à fait. Il y a beaucoup d'occasions de simplifier. Je veux dire

266
00:35:34.760 -> 00:35:35.809
Jirah Cox : Je veux dire

267
00:35:36.140 -> 00:35:47.330
Jirah Cox : Un petit zoom arrière. Kvm est l'un des hyperviseurs les plus largement déployés dans le monde, n'est-ce pas ? Le vrai truc, nous l'avons enseigné ici. en plus de parler, vous savez, Cvm. C'est pour la haute vitesse. Local storage

268
00:35:47.370 -> 00:35:59.409
Jirah Cox : c'est la facilité de gestion, comme, vous le savez, l'intégrer dans la famille. C'est ça ? Vous le gérez avec prism. Il n'y en a pas vraiment si vous savez déjà comment faire fonctionner de nouveaux réservoirs et gérer un V est en quelque sorte un non problème, n'est-ce pas ? Vous le gérez comme n'importe quel autre cluster.

269
00:35:59.490 -> 00:36:02.620
Jirah Cox : la simplicité est donc de mise.

270
00:36:03.730 -> 00:36:10.370
Philip Sellers : Oui, c'est amusant, Andy, vous avez posé une question sur la case à cocher permettant d'activer la réservation Ha. Vous savez

271
00:36:10.560 -> 00:36:30.449
Philip Sellers : J'ai exploré la nouvelle plate-forme fiscale et j'y ai trouvé beaucoup de choses. Cela me rappelle les premiers jours de Vmware, où il était facile de créer des clusters. Il suffisait d'entrer et de cocher la case, et vous aviez un cluster. Et je me souviens d'avoir fait des fenêtres. Il fallait deux semaines pour mettre en place et configurer les clusters et résoudre tous les bogues avant cela.

272
00:36:30.480 -> 00:36:46.710
Philip Sellers : Il y a aussi beaucoup de cela dans la plateforme. simplicité. Ils ne le sont pas. Le tennis fait du bon travail en livrant quelque chose de complexe sous les couvertures d'une manière simpliste, en l'opérant d'une manière simpliste.

273
00:36:46.730 -> 00:36:53.059
Philip Sellers : Ce sont des choses qui, je pense, résonnent chez les technologues lorsqu'ils ont l'occasion de voir

274
00:36:53.210 -> 00:36:56.059
Philip Sellers : ce qui leur est livré.

275
00:36:56.190 -> 00:36:59.699
Philip Sellers : Oui, j'ai examiné d'autres hyperviseurs, l'un d'entre eux provenant d'une société d'assurance.

276
00:37:00.640 -> 00:37:10.499
Philip Sellers : une grande société de logiciels qui pourrait écrire des systèmes d'exploitation, et vous savez que c'est maladroit. Il. Il faut un peu de

277
00:37:10.680 -> 00:37:19.239
Philip Sellers : Des étapes supplémentaires. Vous savez, c'est le clustering de la vieille école que vous connaissez de Windows. C'est la même chose sur hyperv, et

278
00:37:19.390 -> 00:37:26.160
Philip Sellers : Il y a quelque chose à dire sur le message simpliste et sur la manière dont les mécaniciens le transmettent.

279
00:37:26.860 -> 00:37:37.849
Andy Whiteside : Je pense que l'une des caractéristiques de Newton est qu'il est né avec les mêmes processus, concepts et constructions hyperconvergents. C'est qu'il est né avec les mêmes processus, concepts et constructions hyper convergents, et dès le premier jour

280
00:37:38.240 -> 00:37:43.420
Andy Whiteside : ce n'est pas quelque chose qui a dû, vous savez, trouver sa place dans la solution. C'est ainsi qu'elle est née.

281
00:37:43.530 -> 00:37:50.110
Andy Whiteside : et vous savez, il est parfois utile de s'ennuyer à une époque où l'avenir est là plutôt que d'avoir à s'y adapter.

282
00:37:50.860 -> 00:37:53.120
Jirah Cox : Oui, c'est assez juste. Je veux dire que les

283
00:37:53.360 -> 00:37:57.720
Jirah Cox : C'est le point que j'aime faire valoir. On me l'a enseigné il y a des années. C'est comme

284
00:37:57.920 -> 00:38:16.470
Jirah Cox : Tout système suffisamment performant pour fonctionner et résoudre des problèmes commerciaux de cette complexité, n'est-ce pas ? Il s'agit simplement d'une question de conception : demandons-nous aux utilisateurs de supporter cette complexité ? Ou achetons-nous cette complexité ? Pour qu'ils bénéficient d'une partie de cette expérience, il y a une complexité qui s'abstrait sous le capot.

285
00:38:16.540 -> 00:38:32.449
Jirah Cox : J'ai entendu une fois que nous faisons. Nous évaluons tout Vm. Nous évaluons tout Vm sur 7 ou 12 paramètres différents pour déterminer où il va atterrir. Il y a donc beaucoup de décisions qui sont prises sous le capot, mais nous ne demandons pas aux utilisateurs d'attendre dans le feu de l'action et de prendre ces décisions pour nous, si nous le pouvons. Si nous pouvons abstraire et nous le ferons.

286
00:38:32.870 -> 00:38:33.430
C'est vrai.

287
00:38:35.370 -> 00:38:40.269
Andy Whiteside : Eh bien, les gars, nous sommes plus ou moins à court de temps. Ce fut une bonne conversation qui a été

288
00:38:40.520 -> 00:38:41.899
Andy Whiteside : toute autre question

289
00:38:41.940 -> 00:38:43.319
Andy Whiteside : réflexions, commentaires ?

290
00:38:43.580 -> 00:38:53.000
Ben Rogers : Non, je reviens à ce qu'ils ont dit au début du podcast. Il s'agit d'une plateforme. Ce n'est plus seulement un système hyper convergent.

291
00:38:53.010 -> 00:39:10.749
Ben Rogers : et tous les autres produits que nous avons peuvent en quelque sorte s'articuler autour de cette idée de, vous savez, répartir les données à travers le jour du cluster, la résilience, toutes ces choses. Vous voulez en savoir plus ? Prenez contact avec nous. C'est une période passionnante pour Newton. Nous amenons cette technologie dans le nuage. Maintenant.

292
00:39:10.810 -> 00:39:20.549
Ben Rogers : Cela ouvre des portes à de nouvelles techniques de tennis. J'ai hâte de voir ce que l'avenir nous réserve.

293
00:39:22.180 -> 00:39:24.799
Andy Whiteside : Harvey. Qu'avons-nous manqué ? Vous voulez couvrir ?

294
00:39:25.070 -> 00:39:26.959
Harvey Green : Eh bien, puisque vous

295
00:39:27.030 -> 00:39:40.090
Harvey Green : Je rappelle à tout le monde que cette semaine est une semaine de trois vendredis. Nous organisons donc notre atelier le vendredi de

296
00:39:40.270 -> 00:39:46.130
Harvey Green : 11 à 2 cette semaine, c'est le service de base de données sur la mécanique. Donc

297
00:39:46.200 -> 00:39:48.009
Harvey Green : Il ne fait aucun doute qu'il faut sauter sur l'occasion.

298
00:39:48.960 -> 00:39:50.640
Andy Whiteside : Anciennement personne en Amérique

299
00:39:50.820 -> 00:39:52.730
Harvey Green : anciennement connu sous le nom de era.

300
00:39:52.950 -> 00:39:56.609
Jirah Cox : et c'est ça, c'est ça, c'est un atelier téléphonique, n'est-ce pas ? C'est comme

301
00:39:56.750 -> 00:40:01.490
Jirah Cox : qui va bien au-delà de ce genre de Vm. Management, la reconstruction des données. C'est comme

302
00:40:01.650 -> 00:40:08.479
Jirah Cox : piles incluses. Qu'est-ce que la plateforme peut vraiment faire pour vous et vous aider à rationaliser un grand nombre d'opérations de jour. 2 opérations.

303
00:40:08.540 -> 00:40:27.529
Harvey Green : Oui. Je me moque d'un de mes amis parce qu'il me dit toujours que je reviens avec la phrase, qu'est-ce qu'on peut faire d'autre chaque fois qu'il parle de quelque chose ? de ça ? C'est l'une de ces occasions où nous venons de passer à travers. Vous savez, ce podcast entier sur certaines des choses qui sont à la base de la plate-forme entière.

304
00:40:27.630 -> 00:40:33.300
Harvey Green : et ensuite, c'est comme si on se demandait ce qu'on pouvait faire d'autre. Eh bien, vendredi, vous verrez plus de

305
00:40:34.190 -> 00:40:36.209
d'où cela vient.

306
00:40:38.080 -> 00:40:42.290
Philip Sellers : Non, je serai dans le même atelier que lui.

307
00:40:42.590 -> 00:40:50.670
Harvey Green : avec Harvey vendredi. Nous serions ravis de vous voir, vous savez que Bill va faire tout le travail cette fois-ci. Il va s'asseoir et se détendre.

308
00:40:51.620 -> 00:40:55.640
Andy Whiteside : Je ne doute pas que tout se passera bien, Gyra. Une dernière chance, quoi que ce soit.

309
00:41:01.640 -> 00:41:21.150
Jirah Cox : Je ne devrais pas me tromper. Oh, eh bien, nous avons annoncé que la prochaine édition aura lieu à Chicago. Parlez-en à vos équipes de comptes et dites-leur que vous voulez obtenir des laissez-passer. Dites-moi que vous voulez obtenir des laissez-passer. Nous serions ravis de le voir à Chicago lorsque Dot next quittera le monde virtuel pour revenir au monde physique ou quelque chose comme ça. L'analogie se décompose ainsi

310
00:41:21.470 -> 00:41:33.129
Andy Whiteside : Bien. Et si vous cherchez des laissez-passer, si vous renouvelez avec intégrité vos licences existantes avec leurs laissez-passer. Nous allons distribuer, je crois, 20 laissez-passer. Je pense que nous avons l'intention de donner.

311
00:41:33.690 -> 00:41:42.400
Jirah Cox : Nous prévoyons de distribuer les deux broncos que nous distribuons dans la mesure où le travail n'a pas de frontières. lors de l'événement. C'est vrai. Voilà, mec. Je veux être un client centigrade.

312
00:41:42.510 -> 00:41:55.430
Harvey Green : Hé ? Vous devriez l'être. Vous devriez. Ma crainte est que vous n'ayez pas besoin de nous. Mais ce n'est pas grave. Très bien, les gars, nous vous remercions de vous joindre à nous et de faire cela avec nous, et nous le ferons à nouveau dans une semaine ou deux.

313
00:41:56.560 -> 00:41:59.020
Jirah Cox : Ça me paraît bien. Très bien, merci à tous.