Journal Pour utiliser Windows, utilisez Linux

Posté par  .
Étiquettes : aucune
16
7
nov.
2009
J'ai cette petite accroche qui me trotte dans la tête depuis quelques temps: "Pour utiliser Windows, utilisez Linux".

L'idée m'est venu alors que je réfléchissais aux arguments pour et contre la virtualisation utilisée massivement dans notre infrastructure. Dans tous les cas que je connais, un Windows virtualisé fonctionne plus vite qu'un Windows "bare metal". Ce n'est probablement pas vrai pour les jeux et la 3D, mais dans notre groupe d'entreprises nous ne sommes pas sensés utiliser cela sur nos serveurs. Oui, j'ai des principes rétrogrades.

Un simple Windows 2003 faisant office de serveur de fichiers fonctionne _beaucoup_ plus vite en étant virtualisé. Sur la même machine s'entend. Le démarrage est plus rapide, l'accès aux fichiers est plus rapide, sans parler des sauvegardes qui sont d'une efficacité et d'une simplicité inconnue avec Windows (copie des disques virtuels, simple, efficace).

Nous utilisons également des serveurs TSE et SQL pour nos applicatifs principaux. Même chose: c'est _beaucoup_ plus rapide en étant virtualisé (vmware et kvm chez nous). Nous mettons le serveur TSE et le serveur SQL sur des machines virtuelles différentes sur la même machine physique. C'est moins cher, c'est plus rapide. C'est plus sécurisé: le pare-feu Linux est tout de même vaguement mieux que celui de Windows, OpenVPN, etc. Je cherche encore un inconvénient.

Et pour les postes de travail, nous utilisons Linux (enfin plutôt des logiciels libres fonctionnant sous Linux) pour dupliquer les postes, pour récupérer les données des disques qui lâchent, pour bricoler les partitions. Tout ce qui n'est pas correctement faisable avec Windows uniquement.

Question réseau, nos routeurs sont des machines Linux. Avant j'avais du NetBSD sur disquette, c'était terrible aussi. Nos machines de sauvegarde sont sous Linux également.

Bref, tout ce beau monde non-Windows permet de mieux faire fonctionner les produits Microsoft.

Il ne reste plus qu'à remplacer Active Directory par quelque chose qui tienne la route :-) Et faire en sorte que Samba fonctionne _vraiment_ comme un serveur de fichiers Windows (ah oui, c'est le gros point noir de Samba, c'est pour cela que nous gardons nos serveurs Windows pour simplement partager des fichiers).

  • # securité...

    Posté par  . Évalué à 10.

    Pour sécuriser windows , utiliser Linux

  • # Licence

    Posté par  . Évalué à 2.

    Avez vous vérifié que les licences des produits Microsoft utilisés vous permettent ce type d'intégration ?

    • [^] # Re: Licence

      Posté par  . Évalué à 10.

      Les licences ne nous permettent pas de virtualiser ?
      Les licences ne nous permettent pas de dupliquer depuis une image maîtresse ? (nous changeons ensuite les UUID et numéros de licences).

      Si c'est le cas, qu'un avocat tente de nous faire condamner pour ça, je lui souhaite bonne chance :-)

      • [^] # Re: Licence

        Posté par  . Évalué à 9.

        De toute manière, si vous utilisez du XP/2003, les licences de ces derniers ont été rédigées bien avant la mode de la virtualisation et cette dernière n'a donc pas été prise en compte, d'où l'absence de restriction sur ce sujet.

        C'est d'ailleurs pour cela que la licence de Vista a fait couler beaucoup d'encre virtuelle, car elle apportait un gros changement en ne permettant à Windows d'être virtualisé que pour l'édition intégrale.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Licence

        Posté par  . Évalué à 10.

        Je ne sais pas du tout ce que permettent les licences Microsoft, j'ai juste demandé si vous aviez vérifié.

        Sinon, au cas visiblement improbable où l'une des licences interdirait la virtualisation, je pense que la bonne attitude est de respecter la licence. Si on n'accorde pas la même valeur à la licence d'un produit microsoft qu'à la GPL, alors on n'a pas bien compris comment fonctionne le logiciel libre.

        C'est mon respect de la licence Microsoft qui fait que je n'utilise pas leurs produits.

        • [^] # clause abusive ?

          Posté par  . Évalué à 10.

          Je ne sais pas du tout comment déterminer si une clause est abusive, mais dans certains cas, la licence peut contenir des points qu'on n'est pas tenu de respecter.

          • [^] # Re: clause abusive ?

            Posté par  . Évalué à 4.

            Clair, moi c'est le coup de redistribuer des trucs avec la GPL, je considère que je peux ne pas respecter ça…

      • [^] # Re: Licence

        Posté par  (site web personnel) . Évalué à 5.

        Les licences ne nous permettent pas de virtualiser ?

        Microsoft a effectivement interdit la virtualisation de certaines version de Vista :
        http://www.vmware.com/fr/interfaces/licensing/desktop.html
        http://www.zdnetasia.com/news/software/0,39044164,61969665,0(...)

        Mais bon, il s'agit de la version "Family", donc je ne pense pas que vous ayez ce type de versions sur vos vos serveurs.

        Après, j'imagine que vos licences de Windows sont des accords d'entreprise (qui permettent de ne pas payer les licences unes à une, mais par "lot"). Dans ce cas-là, ce sont peut-être des licences spécifiques, avec des restrictions supplémentaires (qui interdisent par exemple la virtualisation).

  • # ldap, samba

    Posté par  . Évalué à 3.

    Il ne reste plus qu'à remplacer Active Directory par quelque chose qui tienne la route :-) Et faire en sorte que Samba fonctionne _vraiment_ comme un serveur de fichiers Windows (ah oui, c'est le gros point noir de Samba, c'est pour cela que nous gardons nos serveurs Windows pour simplement partager des fichiers).

    LDAP pour remplacer Active Directory

    Samba v3 avec les ACL devrait etre pas mal
    sinon y a Samba v4 qui arrive

    • [^] # Re: ldap, samba

      Posté par  (site web personnel) . Évalué à 6.

      comme un serveur de fichiers Windows (ah oui, c'est le gros point noir de Samba, c'est pour cela que nous gardons nos serveurs Windows pour simplement partager des fichiers)

      Je vois pas ce que tu reproches à Samba ? Je trouve qu'il est même beaucoup plus pratique et fonctionnel qu'un Windows ...

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: ldap, samba

        Posté par  . Évalué à 3.

        là où je bosse on utilise un samba V3+acl...

        Les utilisateurs reprochent le comportement différent de la conservation des permissions lors d'un couper/coller et d'un copier/coller. En effet, on retrouve sous leurs windows et dans les répertoires partagés par le samba le même comportement que mv et cp...

    • [^] # Re: ldap, samba

      Posté par  . Évalué à 7.

      LDAP pour remplacer Active Directory
      Ca se saurait :-)
      Certes LDAP remplace le répertoire, mais les outils d'administration ne fonctionnent pas correctement. Télédéploiement, politiques de sécurité, etc, ça ne fonctionne pas comme il faut.

      Pour Samba v4 j'attends effectivement. Mais je ne pense pas que ça résolve les problèmes inhérents aux différences en Unix et Windows. En particulier l'héritage des permissions et les permissions un poil fines. C'est indiqué clairement dans la documentation Samba. Je doute qu'ils reviennent dessus.
      Egalement (de tête, à re-vérifier) les postes clients ne peuvent pas modifier les permissions comme d'habitude.
      Bref, le remplacement pose-et-ça-fonctionne-pareil, ce n'est pas ça.

  • # plus vite ?

    Posté par  . Évalué à 5.

    comment peut-on expliquer que Windows fonctionne beaucoup plus vite en étant virtualisé ?
    je suis surpris.

    quelle solution de virtualisation avez-vous choisie ?

    • [^] # Re: plus vite ?

      Posté par  . Évalué à 3.

      C'est peut-être une histoire de pilotes ? J'imagine que les pilotes pour utiliser les disques physiques ne sont pas les même que ceux des disques virtuels (certainement fournis par la solution de virtualisation, comme VMware), et que ces derniers sont plus performants.

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: plus vite ?

      Posté par  . Évalué à 4.

      d'une manière générale, je suis d'accord avecle gain de vitesse, mais du moins sous VirtualBox, ce n'est pas le cas pour tout. L'affichage par exemple n'est pas aussi rapide en virtualisé, je suppose du à un manque d'optimisation ou à la quantité de données à gérer à ce sujet. Bref, il y a un manque de réponse de l'interface.

      Par contre, c'est vrai que je suis toujours stupéfait de voir à quelle vitesse il démarre ...

      • [^] # Re: plus vite ?

        Posté par  . Évalué à 5.

        Ça peut peut-être venir du fait que linux met en cache dans la mémoire vive les fichiers quand elle est disponible.

        Dans ce cas, tu passerais de la lecture d'un disque dur (lent), à de la mémoire vive (très rapide). Si l'image est très petite, ça peut aller vite.

        Envoyé depuis mon lapin.

        • [^] # Re: plus vite ?

          Posté par  . Évalué à 2.

          Ça serait pas surtout lié à la détection et à l'initialisation du matériel qui n'est pas à faire dans le cas d'une machine virtuelle ?

      • [^] # Re: plus vite ?

        Posté par  . Évalué à 4.

        Sauf que l'affichage, pour des serveurs.. :+p

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: plus vite ?

      Posté par  . Évalué à 10.

      Nous utilisons vmware-server (le truc basique qui fonctionne parfaitement bien) et KVM (le truc en version post-béta qui a encore plein de bugs mais qui marche du tonnerre).

      Je pense que Windows gère mal son cache et ses accès disque. Une simple compression avec 7-Zip d'un gros fichier est plus rapide sur vmware+Windows que sur Windows.

      Mais le top c'est avec les applications codées avec les pieds (la majorité donc). Qui font des accès aux fichiers par petits bouts. Nous avons par exemple une application codée en... j'ai honte pour le programmeur... en Clarion (bon, lui il en est fier). Il fait l'équivalent d'un sync à chaque écriture dans un fichier. Lorsqu'un ordinateur client fait un recalcul de statistiques par exemple, il y a des millions de syncs. Sur un Windows bare-métal ça prend des plombes: les disques sont en activité permanente. Le pilote vmware pour les disques n'honore pas les syncs. Donc le Linux sous-jacent récupère tranquillou les écritures, les stocke dans le cache, et une fois toutes les 4 secondes tu as la loupiotte des disques qui s'allume brièvement.
      Windows: 1h30
      vmware+Windows: 3 minutes
      Ce n'est pas "de la faute" de Windows, certes. Mais dans ce cas précis, nous avons 30 fois plus de performance (trente !).

      Samba par défaut n'honore pas non plus les syncs. C'est écrit dans la doc du genre "les dév Windows sont des brêles, Samba n'honore pas les syncs car ils ne servent à rien dans 99,9% des cas".
      En fait il est indiqué "Many Windows applications (including the Windows 98 explorer shell) seem to confuse flushing buffer contents to disk with doing a sync to disk."

      Si on a des disques avec pas mal de cache, on ne voit pas ce problème. Ca coûte juste nettement plus cher (SAS haut de gamme au lieu de SATA ordinaire).

      Pour nos serveurs SQL c'est pire: la mémoire du Linux sous-jacent a 12 Go de libre, utilisé pour le cache-disque. L'ensemble des bases utiles de notre plus gros logiciel fait environ 30 Go. En utilisation quotidienne, la totalité des données utile se trouve dans le cache Linux. Cela fait qu'on utilise les disques quasi-uniquement en écriture. Ca aide :-)
      Si on met ces 12 Go dans le Windows, hé bien le disque s'affole. Je pense que Windows ne sait pas gérer un cache-disque.
      Résultat: deux disques SATA ordinaires (RAID 1 logiciel) supportent 180 utilisateurs TSE + un serveur SQL avec 30 Go de données. En Windows bare-métal avec des SAS 15.000 tours + carte RAID on ne passe que 60 utilisateurs avant qu'ils nous insultent au téléphone. Et il faut deux serveurs car TSE+SQL sur la même machine, même pas la peine d'y penser.

      • [^] # Re: plus vite ?

        Posté par  (site web personnel) . Évalué à 1.

        Ton récit est vraiment très intéressant. T'as essayé avec Windows server 2008 R2/7 ? Il me semble avoir lu qu'ils avaient fait des progrès sur le cache disque dans les dernières versions.

        • [^] # Re: plus vite ?

          Posté par  . Évalué à 5.

          T'as essayé avec Windows server 2008 R2/7 ?
          Non :-)
          Je souhaite virer aux maximum Windows (j'ai une trentaine de serveurs de fichiers à passer de Windows à Samba). Je n'ai pas d'argent à dépenser dans des Windows supplémentaires qui, de toutes manières, finirons virtualisées car c'est beaucoup mieux (ne serait-ce que pour les sauvegardes, la migration hyper facile, la sécurité pare-feu vpn, etc).

          Et puis bon, la version de Windows sortie en 2008 gère le cache aussi bien que la version de Linux ou BSD sortie en 1998 ? Belle affaire :-)

      • [^] # Re: plus vite ?

        Posté par  . Évalué à 4.

        y'a une variante plus simple de ça :

        Windows au démarrage (et ensuite) aura besoin de lire et des fois modifier des centaines de fichiers, pilotes, etc éparpillés partout sur le disque, sans parler de la base de registre, de fichiers temporaires, de 50 merdouilles qui croient indispensable d'aller voir si il y a une mise à jour disponible chez l'éditeur...

        quand Windows est virtualisé, en général son filesystem c'est juste un seul gros fichier de quelques centaines de megaoctets ou quelques gigaoctets en un seul endroit, bien délimité et en général mis en cache dès les premières opérations

        donc oui, ça fait vroum, et ce phénomène n'est pas récent.

        (par contre, quand l'hote en dessous se vautre, ça fait souvent prout, et pour de bon)

        • [^] # Re: plus vite ?

          Posté par  . Évalué à 2.

          Mouais, la vitesse de démarrage d'un serveur, on s'en fiche un peu non ? :-)

          Ce qui m'interesse, c'est le fonctionnement "en vrai". Lorsque x utilisateurs accèdent aux ressources.

          • [^] # Re: plus vite ?

            Posté par  . Évalué à 5.

            > Mouais, la vitesse de démarrage d'un serveur, on s'en fiche un peu non ? :-)

            NON.

            soit tu le lances avant d'en avoir eu besoin, c'était planifié et tout...

            soit t'en as besoin là maintenant tout de suite parce que ça venait de planter ou tu as besoin d'un peu plus de capacité (peu importe ce que ca veut dire vraiment) et là ça compte

            un machin qui met 15 minutes à démarrer, s'initialiser puis lancer ses 3000 troucs de conneries de containers EJB en tout genre prout prout machin ça commence à faire long si tes clients commencent à s'énerver au portillon.

            > Ce qui m'interesse, c'est le fonctionnement "en vrai". Lorsque x utilisateurs accèdent aux ressources.

            faut voir. les hotes peuvent être très légers au point d'être vraiment discrets, voire indécelables. par contre ça rajoute une étape réseau en plus

    • [^] # Re: plus vite ?

      Posté par  (site web personnel) . Évalué à 2.

      Nous sommes entrains de virtualiser tous les windows 2003 cela permet d'arrêter quelque serveurs physique (économie d'électricité + cela fait des hôtes de réserve).
      Le gain est surtout que un win 2003 monte plus vite dans une vm que sur une machine en dure (un serveur avec contrôleur raid et la total met du temps à s'initialiser (c'est pas la faute à win)) et comme un linux on le redémarre très rarement.

      Nous avons un serveur d'impression écrit en java qui se plante toutes les semaines sous windows 2003 donc pour redémarrer le windows la vm c'est pratique.
      Le concepteur nous a envoyé une version linux donc je vais l'installer et tester.

      • [^] # Re: plus vite ?

        Posté par  . Évalué à 6.

        Nous avons un serveur d'impression écrit en java qui se plante toutes les semaines sous windows 2003 donc pour redémarrer le windows la vm c'est pratique.
        Le concepteur nous a envoyé une version linux donc je vais l'installer et tester.

        S'il est écrit en java, pourquoi avez-vous besoin d'une version spécifique Linux?
        (À moins que ce ne soit encore un truc écrit par des incompétents qu imettent en dur dans le code des chemins du genre "C:\Program Files\", j'ai déjà vu ça...)

        • [^] # Re: plus vite ?

          Posté par  . Évalué à 2.

          Sans doute le programme utilise du JNI pour certaines opérations.

        • [^] # Re: plus vite ?

          Posté par  . Évalué à 10.

          (À moins que ce ne soit encore un truc écrit par des incompétents qu imettent en dur dans le code des chemins du genre "C:\Program Files\", j'ai déjà vu ça...)

          C'est clair que c'est des noobs !!!

          Moi je mets plutot :

          "C:\\Program Files\\". ça c'est mieux ! :)

        • [^] # Re: plus vite ?

          Posté par  . Évalué à 4.

          S'il est écrit en java, pourquoi avez-vous besoin d'une version spécifique Linux?
          (À moins que ce ne soit encore un truc écrit par des incompétents qu imettent en dur dans le code des chemins du genre "C:\Program Files\", j'ai déjà vu ça...)


          Toi, tu n'as jamais testé les outils d'admin de chez HP, comme la console ILO en Java qui fonctionne sur un linux 32bit mais pas sur un 64...

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: plus vite ?

            Posté par  . Évalué à 3.

            Toi, tu n'as jamais testé les outils d'admin de chez HP, comme la console ILO en Java qui fonctionne sur un linux 32bit mais pas sur un 64...

            Ben, si je l'ai déjà utilisé, mais j'étais sur une machine 32bits.
            Qu'est-ce qu'ils ont pu faire comme horreur pour que ça ne fonctionne pas en 64bits?

            • [^] # Re: plus vite ?

              Posté par  . Évalué à 2.

              Je n'ai plus le message en tête, mais je me souviens après avoir tenté d'utiliser la Remote Console et avoir reçu une exception me disant clairement que les OS 64bits ne sont pas supportés. Ils ont certainement utilisé une classe à la c*n, écrite à la Rache®.

              Résultat, je me trimballe une VM 32bits pour ce genre de cas (heureusement, VirtualBox s'installe tout seul sur Debian, même les modules noyaux).

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.