Derniers messages
Dernier message par Zatalyz - 04 Novembre 2019 à 14:43:05
Cliquez pour afficher le message
Suite au grand plantage de l'autre week-end sur murbaz, j'ai pris un peu en urgence un 3e serveur pour s'assurer qu'on ne perde rien.
Après analyse, Murbaz ne semble pas mourant de façon claire donc on l'a remis en marche. Mais c'est tout de même le moment de se poser la question de l'évolution de notre archi, parce qu'on a de la trésorerie. Pas au point de pouvoir faire n'importe quoi, mais... on a vraiment plus d'options qu'avant. Il faudra attendre un peu pour une confirmation trésorière du montant annuel qu'on peut mettre sur les serveurs mais il faut aussi, ici, qu'on détermine les stratégies les plus intéressantes.
Actuellement, nous avons deux serveurs, Nuxru et Murbaz, qui se sauvegardent mutuellement : Nuxru garde une copie des données de Murbaz, Murbaz garde une copie des données de Nuxru. Il y a des VM sur les deux : le pad et des vm de test sur nuxru, le reste sur Murbaz. Nous venons d'ajouter un 3e serveur (sans nom) qui a des copies de Murbaz, mais d'une façon ou d'une autre il va être modifié.
J'aime bien les questions de blonde, elles sont pleines de bon sens. Je vous remet ma réponse longue (c''était du mail) :
Depuis, je dois dire que l'optique d'avoir un gros serveur avec un vrai service derrière et plus de garanties (et de bande passante) me plaît bien (chez ovh ou ailleurs, mais de la qualité). Nuxru étant étonnament fiable au fil des ans, on peut le garder pour le backup. Mais prendre un vrai serveur cher me semble pertinent si on mutualise avec les copains, sinon ça fait quand même cher et on n'a pas besoin tous les jours d'autant de CPU et de bande passante...
On pourrait aussi viser une solution intermédiaire, avec un serveur moyen de gamme offrant plus de garantie. C'est moins intéressant à mon goût parce que côté performance on ne gagne pas grand chose par rapport au surcoût, encore qu'il faudrait regarder ce que proposent Hertzner, online.net etc...
Si on reste sur la logique les deux serveurs se backupant mutuellement mais avec des serveurs pas cher, il me semble important d'envoyer une deuxième copie de tous les backup sur un 3e serveur, pour une raison très bête : nos deux serveurs sont actuellement dans le même datacenter. Ça, c'est pas bien, en terme de redondance
Et on a bien vu aussi que nuxru, tant que c'est un hyperviseur, est un peu faiblard pour restaurer les sauvegardes (on court après la place sur le disque dur, réservé par les VM).
Dans toutes ces situations, il me semble de toute façon intéressant de transformer Nuxru en "juste du backup" (on vire l'hyperviseur et les vm, donc ça veut dire les mettre ailleurs, mais autant avoir de la ressource pour ça). Nuxru a un avantage important, c'est une vieille offre et on a plus en disque dur que ce qui se fait actuellement (j'ai un mal fou à avoir l'info avec LVM, mais je crois que c'est 3To ?), et il s'est avéré stable ces dernières années.
Il serait bien qu'on se décide dans les jours qui viennent, pour deux raisons :
- éviter de payer le 3e serveur pour "rien" (actuellement il n'est pas configuré pour dédoubler les backups, ou héberger des vm, et suivant ce qu'on décide, on le garde ou on en prends un plus petit)
- il y a en fin de mois un horrible machin capitaliste qui fait qu'on peut espérer des supers promos sur les offres... c'est pas mal de pouvoir économiser les frais, quand même. Pas un argument suffisant (faut qu'on puisse payer même sans la promo) mais si on peut en profiter ce sera aussi bien pour nos finances.
Après analyse, Murbaz ne semble pas mourant de façon claire donc on l'a remis en marche. Mais c'est tout de même le moment de se poser la question de l'évolution de notre archi, parce qu'on a de la trésorerie. Pas au point de pouvoir faire n'importe quoi, mais... on a vraiment plus d'options qu'avant. Il faudra attendre un peu pour une confirmation trésorière du montant annuel qu'on peut mettre sur les serveurs mais il faut aussi, ici, qu'on détermine les stratégies les plus intéressantes.
Actuellement, nous avons deux serveurs, Nuxru et Murbaz, qui se sauvegardent mutuellement : Nuxru garde une copie des données de Murbaz, Murbaz garde une copie des données de Nuxru. Il y a des VM sur les deux : le pad et des vm de test sur nuxru, le reste sur Murbaz. Nous venons d'ajouter un 3e serveur (sans nom) qui a des copies de Murbaz, mais d'une façon ou d'une autre il va être modifié.
Citation de: LyneEst-ce qu'il est plus intéressant (financièrement et/ou technologiquement) d'avoir 3 serveurs, dont un dédié au back-up (et, j'espère, à peu près correct pour ne pas risquer un crash dessus au plus mauvais moment) ? Ou d'avoir 2 serveurs seulement (comme jusqu'à récemment) mais de meilleure qualité / plus robustes ? Ce n'est pas tant le détail de la réponse qui m'intéresse, mais l'avis résumé des chefs maj sur le sujet, hein (je rappelle que je suis blonde
J'aime bien les questions de blonde, elles sont pleines de bon sens. Je vous remet ma réponse longue (c''était du mail) :
Citation de: zatalyzEn fait, les serveurs un peu mieux (type soyoustart, hertzner) ou carrément mieux (offre pro d'ovh et consort) sont vite vraiment plus cher pour des produits équivalents en terme de ram/dd/cpu. Quand on trouve l'équivalent, parce qu'évidement plus c'est cher plus c'est des grosses machines. Pour un ordre d'idée (je vais donner tous les prix HT) :
- nous avons actuellement chez kimsufi un serveur à 10€, qui suffirait pour du backup mais qui n'a pas beaucoup de puissance pour plus, et un autre à 25€ sur lequel tout tourne ou presque. Le serveur de backup que j'ai pris dans l'urgence (dans l'idée qu'on allait ptet devoir faire un transfert des services aussi) est à 14€/mois, on pourrait se contenter de celui à 10€ ou même chercher d'autres offres qui offrent du stockage sans plus et qui seront peut-être moins cher. Ou pas, ces serveurs à 10€ me semblent honnêtes en backup. Donc 35€+14 ou 10€.
- le premier prix soyoustart est à 35€, il est un peu mieux que le kimsufi à 25€ pour le cpu et équivalent sur le reste.
- le premier prix chez ovh est à 53€. À ce prix par contre on a une machine de guerre et des services associés qui déchirent, hein (plus de bande passante, un vrai service de support, 32Gb de ram, un cpu de fou, autant de To sur les disques que sur nos deux serveurs, et un peu de sauvegarde en plus).
La question est cependant pertinente, parce qu'on voit les limites de gitlab actuellement (on aurait besoin de plus de place, plus de cpu, etc). De la discussion qu'on a eu avec play.it, il semble qu'on parte sur la possibilité de mutualiser nos gitlab et dans ce cas, un serveur au top commence à être intéressant s'il héberge nos autres services à côté. Pour rentrer dans un peu de détails techniques, on garderais une technologie de VM (xen ou autre mais on est 3 à maitriser assez xen à présent donc...), il y aurait une VM pour gitlab partagée avec play.it, et d'autres VM pour nos divers besoins. Et là encore, on peut mutualiser, prendre un peu plus puissant pour héberger tout play.it et Khaganat sur les mêmes machines par exemple. Dans cette optique, je garderais cependant le kimsufi à 10€, vidé de toutes les vm à une exception prête et dédié à la sauvegarde. L'exception, c'est si à un moment on se décide à héberger XMPP, je ne veux pas que ce soit sur le même serveur que le reste ; et je veux aussi avoir un bout de serveur externe sur lequel on peut rediriger en cas de gros plantage (comme là) pour dire "on est pas morts". Ceci dit ça consomme pas de ressources, ça
Dans cette optique on serait quand même à quelque chose comme 63€/mois soit 756€, soit 907€ TTC... Et moins souple en cas de souci de trésorerie. Actuellement, si la trésorerie s'effondre, on peut rapatrier les services essentiels sur le serveur à 10€ (les vm ont leur place réservée), couper les services gourmands sans perdre les données (gitlab, le pad, nextcloud). Si on met tout sur un gros serveur et que le petit est réservé au backup, il va falloir que tout la place soit là pour le backup... et donc en cas de rétropédalage ça sera un peu plus le bordel, et il faudra sortir des sous (reprendre un petit kimsufi en plus) avant de pouvoir fermer le gros. Et ça demandera plus de temps aussi. D'un autre côté, je n'envisage pas que notre croissance diminue
Voilà pour les éléments de réflexion...
Depuis, je dois dire que l'optique d'avoir un gros serveur avec un vrai service derrière et plus de garanties (et de bande passante) me plaît bien (chez ovh ou ailleurs, mais de la qualité). Nuxru étant étonnament fiable au fil des ans, on peut le garder pour le backup. Mais prendre un vrai serveur cher me semble pertinent si on mutualise avec les copains, sinon ça fait quand même cher et on n'a pas besoin tous les jours d'autant de CPU et de bande passante...
On pourrait aussi viser une solution intermédiaire, avec un serveur moyen de gamme offrant plus de garantie. C'est moins intéressant à mon goût parce que côté performance on ne gagne pas grand chose par rapport au surcoût, encore qu'il faudrait regarder ce que proposent Hertzner, online.net etc...
Si on reste sur la logique les deux serveurs se backupant mutuellement mais avec des serveurs pas cher, il me semble important d'envoyer une deuxième copie de tous les backup sur un 3e serveur, pour une raison très bête : nos deux serveurs sont actuellement dans le même datacenter. Ça, c'est pas bien, en terme de redondance
Et on a bien vu aussi que nuxru, tant que c'est un hyperviseur, est un peu faiblard pour restaurer les sauvegardes (on court après la place sur le disque dur, réservé par les VM). Dans toutes ces situations, il me semble de toute façon intéressant de transformer Nuxru en "juste du backup" (on vire l'hyperviseur et les vm, donc ça veut dire les mettre ailleurs, mais autant avoir de la ressource pour ça). Nuxru a un avantage important, c'est une vieille offre et on a plus en disque dur que ce qui se fait actuellement (j'ai un mal fou à avoir l'info avec LVM, mais je crois que c'est 3To ?), et il s'est avéré stable ces dernières années.
Il serait bien qu'on se décide dans les jours qui viennent, pour deux raisons :
- éviter de payer le 3e serveur pour "rien" (actuellement il n'est pas configuré pour dédoubler les backups, ou héberger des vm, et suivant ce qu'on décide, on le garde ou on en prends un plus petit)
- il y a en fin de mois un horrible machin capitaliste qui fait qu'on peut espérer des supers promos sur les offres... c'est pas mal de pouvoir économiser les frais, quand même. Pas un argument suffisant (faut qu'on puisse payer même sans la promo) mais si on peut en profiter ce sera aussi bien pour nos finances.
Dernier message par Zatalyz - 09 Octobre 2019 à 16:18:35
Cliquez pour afficher le message
Bonjour à toutes et à tous,
Notre gitlab montre ses limites, et nous avons évoqué la possibilité de faire un partenariat avec ./play.it sur ce service.
Cela amène pas mal de questions ; nous travaillons tout ça sur ce pad :
https://pad.khaganat.net/p/gitlab
Et sur le canal Krypte sur XMPP.
Complétez le pad. Posez vos questions, réflexions, etc, ici ou sur XMPP.
Notre gitlab montre ses limites, et nous avons évoqué la possibilité de faire un partenariat avec ./play.it sur ce service.
Cela amène pas mal de questions ; nous travaillons tout ça sur ce pad :
https://pad.khaganat.net/p/gitlab
Et sur le canal Krypte sur XMPP.
Complétez le pad. Posez vos questions, réflexions, etc, ici ou sur XMPP.
#83
Programmation / Re : Xen
Cliquez pour afficher le message
Bonsoir 
,
Il s'agit de la commandermp rpm, elle est dédié aux systèmes d'exploitations à base de Red Hat, il faut regarder de la commande dpkg sous Debian. Essaye ceci :
Si vous avait un accès physique a vos serveurs de test et de prod, je vous invite à regarder le projet suivant : https://xcp-ng.org/
Bonne soirée
,Citation de: mdoukermp permet de voir si un paquet est installé et s'il tourne : https://www.system-linux.eu/index.php?post/2008/12/21/Commande-rpm
Il s'agit de la commande
Code Sélectionner
dpkg-query -L *xen*CitationCela correspond tout à fait à ce que l'on envisage de faire. À savoir, enlever le serveur sous Debian 6 et migrer sur une autre machineEn ce qui concerne les machines virtuelles, je vous conseille de faire un essai en laboratoire (environnement de test) afin de vérifier le bon fonctionnement de ses dernières sur la nouvelle installation de votre hyperviseur.
Si vous avait un accès physique a vos serveurs de test et de prod, je vous invite à regarder le projet suivant : https://xcp-ng.org/
Bonne soirée
#84
Programmation / Re : Xen
Cliquez pour afficher le message
Bon alors là mille pardons 
Cela correspond tout à fait à ce que l'on envisage de faire. A savoir, enlever le serveur sous Debian 6 et migrer sur une autre machine
@shepeng
rmp permet de voir si un paquet est installé et si il tourne : https://www.system-linux.eu/index.php?post/2008/12/21/Commande-rpm
Merci,
Mdouke
Cela correspond tout à fait à ce que l'on envisage de faire. A savoir, enlever le serveur sous Debian 6 et migrer sur une autre machine
@shepeng
rmp permet de voir si un paquet est installé et si il tourne : https://www.system-linux.eu/index.php?post/2008/12/21/Commande-rpm
Merci,
Mdouke
#85
Programmation / Re : Xen
Cliquez pour afficher le message
Je connais pas la commande rmp, c'est sensé faire quoi rmp qa xend ?
#86
Programmation / Re : Xen
Cliquez pour afficher le message
Utilisez-vous lvm ?
Reste-t-il de la place sur le disque ?
Essayez de lancer vos commandes dans un screen ou un tmux comme ça s'il casse la session c'est le screen ou le tmux qui déconnecte et pas la connexion ssh.
Que disent les logs quand vous essayez de lancer xend ?
Reste-t-il de la place sur le disque ?
Essayez de lancer vos commandes dans un screen ou un tmux comme ça s'il casse la session c'est le screen ou le tmux qui déconnecte et pas la connexion ssh.
Que disent les logs quand vous essayez de lancer xend ?
#87
Programmation / Re : Xen
Cliquez pour afficher le message
moi je pense qu'à ce stade, le plus simple est de faire les migrations directement sans s'occuper de xen dans un premier temps :
1 - désinstaller xen et ne garder que des noyaux non xen
2 - migrer squeeze->wheezy->jessie->stretch
3 - installer xen
4 - réparer les VM
1 - désinstaller xen et ne garder que des noyaux non xen
2 - migrer squeeze->wheezy->jessie->stretch
3 - installer xen
4 - réparer les VM
#88
Programmation / Re : Xen
Cliquez pour afficher le message
CitationSalut les gars,Y'a aussi des filles
Y'aurais pas le mail, je te proposerais de faire moi-même la migration
Mais il y a moyen de migrer l'hyperviseur en laissant les VM avec de vieilles versions d'OS (pour commencer).Bon, déjà, c'est assez sûr, Xen n'est pas lancé. Ça c'est le tout premier point. D'ailleurs... Du coup les mails et l'app ne fonctionnent pas ? ou si ? Si oui, il se passe un truc réellement étrange (mais je ne connais pas votre archi, si vous avez plusieurs serveurs par exemple qui font de la redondance ?)
Je ne sais pas combien tu as d'utilisateurs qui risquent d'être impactés par les bidouilles. Si c'est du genre petite asso, que les mails, app et site soient indisponibles quelques heures voir quelque jours est acceptable, s'il y a des "clients" ou beaucoup de monde ça sera plus délicat. Quoi qu'il arrive, communique en amont parce qu'il va y avoir des interruptions de service, c'est assez sûr. Ça passera mieux si les gens sont prévenus. Sans entrer dans les détails techniques forcément (la plupart des gens n'y comprennent rien et s'en moquent), mais donne une durée potentielle pour les "troubles" et prévoit large.
Ensuite, vu les bidouilles à faire, la première chose à vérifier est que ton système de backup marche bien.
Une fois la partie "backup" vérifiée, et les utilisateurs prévenus, on va pouvoir passer aux bidouilles en tout genre.
Là, je te conseillerais bien de tester en local ou sur un second serveur d'installer une debian+Xen à jour, puis de transférer des clones de tes VM, de les lancer et de voir si ça tourne (sans faire de mise à jour sur les VM même, encore une fois ; y'aura que l'hyperviseur à jour).
Si vous avez des sous, prendre un second serveur est vraiment le meilleur plan, vous résilierez le précédent à la fin si tout se passe bien.
Les noms de domaines ne seront pas bons sans les redirections DNS (et à ce stade osef), donc il y aura des erreurs, mais voir si côté système tout marche, déjà : xen se lance, les vm se lancent, elles ont un lot d'erreur "logiques", elles arrivent à communiquer avec le reste d'internet. Si c'est le cas, double allelluia : ça supportera l'upgrade, ce qui veut dire un hyperviseur qui ne sera plus exposé à diverses failles de sécurités, et tu auras un truc fonctionnel en backup. Et quelque part, ta migration aura commencé sans en avoir l'air. Mais pour cloner une VM, il faut l'éteindre... Si Xen est down en principe elles ne sont donc pas lancées. J'espère qu'elles utilisent LVM, parce que dans ce cas, il suffit de suivre ce tuto (et il y a probablement plus élégant, mais chez nous ça a marché).
Note qu'en gros je te conseille de faire une migration en mode pas à pas
mais je pense vraiment que c'est le mieux à faire ; il y a vraiment pas mal de trucs de sécu corrigés dans les dernières versions de Debian et de Xen (et avec ssh aussi, arghhhh). Il est possible que vos soucis viennent de l'exploitation d'une faille : on ne va pas psychoter sur ça (y'a pleins de raisons possibles), mais le mieux est de mettre à jour sans transférer d'éventuels trucs compromis, donc de partir d'un hyperviseur neuf, où tu vas remettre tes règles iptables en regardant bien ce qui est ouvert et pourquoi, transférer les éventuels scripts en vérifiant qu'ils ne sont pas corrompus, et laisser tout ce qui est système sur l'ancien serveur. Cette partie là n'est pas complexe, promis, il faut juste prendre le temps de vérifier au fur et à mesure que tout marche comme attendu.Si ces étapes-là fonctionnent bien, on pourra voir pour mettre aussi les VM à jour. C'est le passage le plus délicat. Celle dont tu dis "qui gère les noms de domaines" j'imagine que c'est le proxy ; s'il est bien pensé, ça sera facile à mettre à jour et augmentera considérablement la sécurité de l'ensemble. Par contre, le mail, je ne touche pas, je sais juste que c'est complexe. Et l'app, suivant le langage et ce qu'elle fait, idem, ça peut être facile ou complexe. Mais là aussi, il y a des astuces pour tenter une mise à jour sans tout casser irrémédiablement, grâce aux snapshots et clones. Pour te donner un ordre d'idée, nous avons eu un souci similaire avec notre site internet, qui héberge divers CMS. L'upgrade risquait de mettre un bazar monstrueux. Nous avons donc laissé tourner l'ancienne VM, et à côté nous avons créé une seconde VM, où on a installé tous les CMS, puis transférer les données. Lorsque cette seconde VM a été opérationnelle (et à jour), on a mis la précédente en lecture seule, fait une dernière synchronisation des données, changé la redirection et hop ! c'était à jour. Bon, avec les moyens de bénévoles sans trop de temps et pas toujours toutes les compétences, mettre cette VM en place aura demandé quasi un an de tâtonnement... mais on y est arrivé
Bon courage, on reste présent pour aider. N'hésite pas sur toutes les questions, si ça va trop vite, ou au contraire si on te dit des trucs un peu trop évident. On peut aussi solliciter un réseau de sysadmin pour voir si quelqu'un serait dispo pour vous faire ça, mais uniquement si ça te semble la chose à faire : personnellement je n'aime pas que les inconnus puissent tripatouiller mes serveurs et tous les sysadmins de Khaganat ont mis du temps avant d'accéder à nos machines, le temps de bien se connaître.
#89
Programmation / Re : Xen
Cliquez pour afficher le message
Salut les gars,
Merci pour vos réponses.
C'est un serveur qui est sous Debian 6.0.10. Oui je sais c'est très très vieux avec un Xen 4.0. A vrai dire, on n'a jamais fait de migration de peur de tout casser car dessus on a une VM qui gère les noms de domaines et une autre pour les mails et une autre pour une app.
Alors pour répondre à vos interrogations :
uname -a renvoie:
Linux xxxx 2.6.32-5-xen-amd64 #1 SMP Fri May 10 11:48:05 UTC 2013 x86_64 GNU/Linux
xm list renvoie:
Error: Unable to connect to xend: Connection refused. Is xend running?
(ou xl list c'est pareil)
Et si je fais un simple xend --version, il se déconnecte de la session ssh.
Nous ne saurions pas faire une migration. Si vous connaissez quelqu'un qui pourrait le faire, moynnant rémunération, ça peut nous intéresser.
Merci,
Mdouke
Merci pour vos réponses.
C'est un serveur qui est sous Debian 6.0.10. Oui je sais c'est très très vieux avec un Xen 4.0. A vrai dire, on n'a jamais fait de migration de peur de tout casser car dessus on a une VM qui gère les noms de domaines et une autre pour les mails et une autre pour une app.
Alors pour répondre à vos interrogations :
uname -a renvoie:
Linux xxxx 2.6.32-5-xen-amd64 #1 SMP Fri May 10 11:48:05 UTC 2013 x86_64 GNU/Linux
xm list renvoie:
Error: Unable to connect to xend: Connection refused. Is xend running?
(ou xl list c'est pareil)
Et si je fais un simple xend --version, il se déconnecte de la session ssh.
Nous ne saurions pas faire une migration. Si vous connaissez quelqu'un qui pourrait le faire, moynnant rémunération, ça peut nous intéresser.
Merci,
Mdouke
#90
Programmation / Re : Xen
Cliquez pour afficher le message
Bonjour,
Il manque quelques informations pour pouvoir te répondre :
Sur quel système d'exploitation tourne ton Xen ?
Quelle est la version de ton système d'exploitation ?
Que retourne la commande uname -a ?
Nota: attention toutefois, ta version de Xen n'est plus maintenue depuis 2015, la préparation et l'exécution d'une mise à niveau est plus que recommandé.
https://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases
Nota 2: Le passage de Xen 4.0 a Xen >= 4.1 entraîne le changement des commandes de Xen.
https://wiki.xenproject.org/wiki/Migration_Guide_To_Xen4.1%2B#Toolstack_upgrade_notes
Il manque quelques informations pour pouvoir te répondre :
Sur quel système d'exploitation tourne ton Xen ?
Quelle est la version de ton système d'exploitation ?
Que retourne la commande uname -a ?
Nota: attention toutefois, ta version de Xen n'est plus maintenue depuis 2015, la préparation et l'exécution d'une mise à niveau est plus que recommandé.
https://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases
Nota 2: Le passage de Xen 4.0 a Xen >= 4.1 entraîne le changement des commandes de Xen.
https://wiki.xenproject.org/wiki/Migration_Guide_To_Xen4.1%2B#Toolstack_upgrade_notes
