Je dois vous avertir tout de suite: ce ne sont pas les histoires
où le rat a été mis à la poubelle . Juste différentes petites histoires "comment les gens font" qui peuvent être utiles aux administrateurs. Et ils ne le sont peut-être pas. Nous avons de nombreux clients assez importants et, par conséquent, ils ont des administrateurs compétents. Par expérience, je dirai: c'est souvent plus expérimenté là où il y a des restrictions budgétaires strictes.
Nous avons un client qui revend notre cloud (il s'est avéré), il y a un contrôle sur la cuisson du pain à partir du cloud, il y a même un CTF déployé pour former les pirates. Mais commençons par les traversées, y compris celles qui sont survenues à cause des routes excavées de Moscou excavées par des excavateurs.
Débit de données le plus élevé
Passer du centre de données de la région à
notre cloud . Puisqu'il y a beaucoup de données, le client a décidé de simplement charger les disques dans un camion ordinaire. Comme tout ne s'est pas bien passé avec le camion, il a donc conduit dans un compartiment du train. J'imagine directement: j'ai tout acheté dans le compartiment, je l'ai forcé dans des boîtes avec du fer, je me suis enfermé et paranoïaque. En conséquence, j'ai établi notre record de vitesse de transfert de données, comme dans la vieille blague sur un camion avec des disques.
Mouvements de masse
Lorsque Moscou a commencé à être déterrée, toute une vague de demandes de déménagement nous a été adressée. Quelqu'un a coupé le câble d'alimentation, et pendant qu'il était réparé, les gens se sont rendus dans le cloud (puisque nous migrons rapidement sous garantie vers le contrat). Regardé de plus près, est resté, transférant lentement les applications de leur serveur vers nous alors que le matériel est retiré de la garantie.
L'histoire la plus intéressante a été celle d'une petite salle de serveurs à Khimki. Là, le directeur financier n'a pas donné d'argent pour la modernisation en principe, ils ont exploité le fer en cycles de 5-6 ans.
La conséquence logique de cette approche est qu'à la fin du cycle tout respirait dans l'air et qu'il y avait des problèmes même avec les disques de la base de données de combat. Chaque semaine, quelque chose en sortait, ils examinaient les applications les moins critiques et les coupaient. En conséquence, les fouilles effectuées par les excavateurs de Khimki ont donné aux administrateurs une chance rare d'accepter néanmoins de passer au cloud.
Une histoire similaire s'est produite lors de la reconstruction de l'autoroute Kaluga, mais là, la société a immédiatement déplacé le bureau dans le cadre de cette entreprise et a décidé de ne pas créer un nœud de serveur dans un nouvel endroit, mais d'aller directement à notre centre de données.
Déplacement urgent
Si vous devez vous déplacer de toute urgence, vous pouvez simplement apporter un stockage physique. Il y a de telles histoires, et non sans curiosités. L'administrateur du client nous a donné le fer à repasser, dit: "Surcharge". "Qu'est-ce que c'est?" - nous demandons. «Toutes sortes de documents importants», répond-il. Les fichiers ont commencé à être traînés - l'administrateur lit simplement leurs noms et rampe le long du mur en riant. Sur le partage de fichiers avec des documents importants, qui, en fait, près de 9 To ont été collectés, se trouve la série «House MD». Naturellement, ils ont ensuite nettoyé que le client n'avait pas supprimé à la hâte.
Lecteur flash oublié
Nous avons déployé un nouvel environnement après avoir déménagé comme prévu. Nous récupérons les candidatures avec les administrateurs du client, puis on se claque sur le front. Il dit: "Ils ont oublié le lecteur flash." Eh bien, j'ai oublié et oublié, puis apportez. Affaires quelque chose. Il s'avère que ce n'est pas seulement un lecteur flash, mais une clé d'autorisation pour une application critique pour l'entreprise. J'ai dû me précipiter dans l'ancien centre de données la nuit, trouver un lecteur flash dans l'un des serveurs, l'arracher et venir chez nous. Nous l'avons inséré dans un concentrateur USB standard pour le cloud, présenté à la machine virtuelle comme s'il était coincé dans un port physique, tout s'est passé.
Surveillez dans le cloud
Appel: "Avez-vous un moniteur dans le cloud?" Nous: "QUOI?" Client: "Eh bien, je prends le serveur ici, l'accès à distance n'est pas configuré dessus. Besoin d'un moniteur dans le cloud. " Comme il s'est avéré plus tard, ils ont acheté un nouvel ordinateur de bureau (à propos du niveau de jeu) et y ont déployé des services. La configuration est presque comme un serveur, ils l'ont remplie de mémoire presque à la limite. Il a donc été amené dans le cloud, coincé dans un vilan avec ses machines virtuelles et parti. Quand il tombe en panne, ils s'en débarrassent, mais pour l'instant c'est juste maladroit dans le rack et rivalise avec les serveurs en vitesse. Nous avions un moniteur, nous l'avons donc installé.
Mise à l'échelle automatique
L'un des principaux clients de détail a une mise à l'échelle automatique, c'est-à-dire la consommation de ressources selon les besoins. Ils ont un système de surveillance Zabbix, des déclencheurs pour charger chaque service y sont configurés. Disons les nœuds Web. Lorsque la moyenne de charge atteint 0,8, Zabbix extrait le script Terraform externe et crée une nouvelle machine virtuelle via l'API. Il se glissera dans l'utilisation d'Ansible, les paquets sont rassemblés, une version est en cours. L'équilibreur le reçoit et met à jour la configuration. Le déploiement prend 5 à 10 minutes. Lorsque la charge totale chute à un certain niveau, c'est ce nœud qui est supprimé.
Leur base de données est configurée comme maître-maître, elle est donc également facilement évolutive. Soit dit en passant, les performances des disques avec nous sont généralement correctement mises à l'échelle par une demande à l'API, eux et un certain nombre d'autres clients l'utilisent activement.
Au final, comme une béquille, mais magnifique. Économies d'environ 25 à 30% une fois entièrement préparé pour les pics.
Mise à l'échelle automatique pour Legacy
La société d'État a procédé à une nouvelle mise à l'échelle. Ils ont une architecture héritée (lire: quelque chose fonctionne sur Fortran, quelque chose sur le demi-axe, à certains endroits, vous devez exécuter l'ancien hyperviseur dans le nouvel hyperviseur pour des raisons de compatibilité). Ils ne peuvent pas coller ensemble sur les voitures horizontalement. Mais ils éteignent leurs machines virtuelles la nuit et les redémarrent avec un type de ressources simple. Dans l'après-midi - les machines cloud les plus puissantes, à 12 nuits, elles s'arrêtent partiellement et démarrent à la place de la même manière, mais beaucoup moins cher, avec un accès plus lent aux disques et avec des quotas différents pour les cœurs. Il jette sa tête sur Exapark - notre système qui pend de l'extérieur. À 6 h 7, tout se répète dans l'ordre inverse. Cette fonctionnalité est disponible pour tous les clients du cloud, mais c'est ici que les administrateurs savaient directement exactement ce qu'ils voulaient et comment. Le résultat est une bonne économie, car le paiement des ressources cloud est horaire.
Type d'accès inhabituel
Nous avons un stockage d'objets compatible AWS. En règle générale, il est généralement utilisé comme S3. Mais l'un des clients postule directement via une application mobile sans redéploiements intermédiaires. Une application pour les applications iOS et Android, des milliers de marchandiseurs y travaillent. Ils y téléchargent toutes les photos et les rapports. Directement des téléphones portables au stockage d'objets. Soit dit en passant, les applications sont écrites à l'aide du kit SDK AWS, uniquement d'autres points de terminaison.
Nous tirons l'interrupteur dans un mois
Il existe une entreprise qui achète des entreprises prêtes à mourir et prolonge leur vie. Il y avait une entreprise française qui, en raison de sanctions, était sur le point de quitter la Russie. Nos clients surenchérissent sur l'entreprise. L'ensemble de l'infrastructure française se trouvait à Moscou dans un bureau ordinaire, un rack de serveurs très dense. Pendant un mois, il a fallu tout transférer en une seule fois dans le cloud. Si vous n'avez pas le temps - coupez simplement la lumière et c'est tout. Et il y a des expéditions depuis des entrepôts, des voitures attendent. Et certaines choses ne pouvaient toujours pas être vérifiées tant que l'ancienne infrastructure n'était pas complètement éteinte. Naturellement, nous ne voulions pas rester sans envois le premier jour, nous avons donc convenu avec les administrateurs que dimanche avant la fin du mois, ils ont éteint le nœud du serveur de bureau, nous regardons comment tout se déroule. A augmenté. Une autre difficulté résidait dans le fait que la société mère ne donnait pas accès aux moyens natifs de transfert de la base de données, elle en souffrait également.
En partant, éteignez la VM
L'un de nos clients - l'agrégateur - est presque entièrement composé de développeurs. Ils sont très rapides et très bien faits. Nous avons principalement conduit dans le cloud pour des environnements de test. Auparavant, ils avaient des problèmes avec le fait que de nombreuses équipes de développement différentes sont venues voir l'administrateur et ont lancé: «Donnez des ressources». On ne savait pas combien cela valait: il n'y avait pas de division budgétaire, elle était considérée manuellement. Ils se sont déplacés vers notre cloud, ont tout couvert avec des scripts d'automatisation et se sont promenés. Après le premier jour, ils n'avaient pas une seule entrée dans l'interface graphique et seulement quelques entrées dans la console - ils font tout dans une infrastructure très automatisée. Leurs outils d'automatisation peuvent déployer ce qu'ils veulent à tout moment. Maintenant la claque des financiers - ils demandent, "en partant, d'éteindre la voiture". Pour qu'après les tests, tout le monde se nettoie après lui-même. Étant donné qu'ils écrivent leur infrastructure entièrement sous forme de code (IaaC), je pense qu'ils automatisent également cela. Si ce n'est pas encore fait.
Un autre développeur avait une image similaire - ils ont utilisé nos fonctionnalités standard pour la comptabilité des projets. Ce sont des rôles distincts pour chaque groupe d'administrateurs: il est clair combien d'argent est dépensé pour quel type d'activité. La comptabilité de projet est un rôle grâce auquel vous pouvez essentiellement créer des clouds privés et y déployer des ressources. Les droits et accès sont coupés à votre guise, il y a des limites supérieures, il y a une facturation séparée.
Utilisation amusante
Nous ne savons généralement pas comment les clients utilisent notre cloud. Mais parfois, les administrateurs eux-mêmes disent et montrent. Donc, notre nœud de chaîne de blocs a été scié, il y a CTF d'une entreprise de sécurité - c'est un simulateur direct du réseau d'entreprise de l'entreprise, vous devez vous y connecter et tout casser. Utilisé pour la formation des employés et des clients finaux. Un autre client coordonne le nettoyage à travers le cloud, il y a une gestion de la boulangerie (ACS TP), il y a un service médical avec des consultations vidéo avec les patients (ils ont une histoire très compliquée avec des données personnelles, il y a un segment dédié et spécialement protégé). Il y a encore quelques clients - certains vendent le service et le deuxième logiciel d'écriture en premier. De différents pays. Et les deux se tiennent côte à côte dans le nuage. Une autre entreprise de vente au détail ne nous accompagne que pour faire face aux pillards - ils ont été coupés une fois par mois de la lumière sur le nœud du serveur. Il y avait des demandes comme un service pour les spammeurs: «Nous voulons être situés en Russie. Envoyer plusieurs millions de lettres par heure. C'est nécessaire dans la Fédération de Russie. Et le logiciel est russe. " Dernier refus. Le contrôleur d'éclairage de l'un des bureaux (éclairage dynamique des intempéries et présence de personnes dans les bureaux) est transmis directement au cloud pour que le prestataire puisse s'y rendre. Il s'agit de notre premier IoT dans le cloud.