1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER.FRENCH

  • =?utf-8?Q?Virtualisation_distribu=C3=A9e_de_?= =?utf-8?Q?machines_(avec

    From roger.tarani@free.fr@21:1/5 to All on Sat Jul 9 19:30:01 2022
    Bonjour,

    Je vise le double objectif suivant :
    1/ permettre à des utilisateurs linux (CLI ou GUI) ou autre win (ou MacOS, mais ça coince un peu apparemment) d'accéder à leur machine devenue virtualisée sur un beau serveru linux ; depuis un poste quelconque muni du client idoine (ssh, x2go, vnc,
    rdp).
    2/ sauvegarder automatiquement ces machines en profitant des capacités de cette architecture (prendre des instantanés automatiques basés sur les blocs modifiés ; prendre un instantané ; restaurer une version d'instantané) ; là c'est un peu flou
    pour moi sauf que l'utilisateur doit pouvoir choisir ce qu'il veut récupérer (au niveau d'une VM) ou au niveau d'un FS à quoi il veut revenir à la manière de Deja Dup/Timeshift/Back in Time/etc., l'équivalent linux d'Apple TimeMachine ; ce qui me
    fait dire qu'il faut en connaître un peu plus pour pouvoir décider !

    Je pense à libvirt qemu/kvm que j'ai déjà expérimenté.
    J'avais peiné longtemps sur les pilotes (redhat, je crois) et n'ai jamais su si j'avais obtenu la performance maximale possible. Mais ça marchait.

    Questions
    1/ L'utilisateur va-t-il retrouver une fluidité indiscutable avec un réseau rapide (FO/ADSL) ? avec un réseau mobile (4G/3G) ?
    et les services habituels (dialoguer avec l'imprimante/le scanner local habituel, vidéoconf)

    2/ Comment assurer les tâches relatives au stockage (Sauvegarder/Synchroniser/Archiver) pour rendre robuste cette architecture ?
    A priori, sauvegarder "ça" (cad les fichiers des VM en cours d'utilisation) est supporté.
    cf. https://www.cyberciti.biz/faq/how-to-create-create-snapshot-in-linux-kvm-vmdomain/

    3/ Si je veux AUSSI que tout ça vive "sur" une architecture robuste distribuée, avec au moins deux serveurs capable de prendre le relais l'un de l'autre, comment faire ?
    Je ne parle pas de cluster HA avec corosync/heartbeat etc. qui requiert une faible latence qui impose que les deux noeuds soient à proximité pour être synchronisés.
    Je parle de deux serveurs distants, capables de prendre le relais l'un de l'autre qui flancherait.
    Tout ça m'évoque des FS distribués que je connais mal ou pas. Mais il vaut mieux en parler avant qu'après ! Je crois que ce sont tout de même des préoccupations orthogonales puisqu'on doit pouvoir y faire tourner ce qu'on veut.

    Merci
    Cordialement
    Roger

    <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>Bonjour,<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Je vise le double objectif suivant :</div><div>1/ permettre à des
    utilisateurs linux (CLI ou GUI) ou autre win (ou MacOS, mais ça coince un peu apparemment) d'accéder à leur machine devenue virtualisée sur un beau serveru linux ; depuis un poste quelconque muni du client idoine (ssh, x2go, vnc, rdp).<br data-mce-
    bogus="1"></div><div>2/ sauvegarder automatiquement ces machines en profitant des capacités de cette architecture (prendre des instantanés automatiques basés sur les blocs modifiés ; prendre un instantané ; restaurer une version d'instantané) ; là
    c'est un peu flou pour moi sauf que l'utilisateur doit pouvoir choisir ce qu'il veut récupérer (au niveau d'une VM) ou au niveau d'un FS&nbsp; à quoi il veut revenir à la manière de Deja Dup/Timeshift/Back in Time/etc., l'équivalent linux d'Apple
    TimeMachine ; ce qui me fait dire qu'il faut en connaître un peu plus pour pouvoir décider !<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Je pense à&nbsp; libvirt qemu/kvm que j'ai déjà expérimenté.</div><div>J'avais peiné
    longtemps sur les pilotes (redhat, je crois) et n'ai jamais su si j'avais obtenu la performance maximale possible. Mais ça marchait.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Questions<br data-mce-bogus="1"></div><div>1/ L'
    utilisateur va-t-il retrouver une fluidité indiscutable avec un réseau rapide (FO/ADSL) ? avec un réseau mobile (4G/3G) ?<br data-mce-bogus="1"></div><div>et les services habituels (dialoguer avec l'imprimante/le scanner local habituel, vidéoconf)<br
    data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>2/ Comment assurer les tâches relatives au stockage (Sauvegarder/Synchroniser/Archiver) pour rendre robuste cette architecture ?</div><div>A priori, sauvegarder "ça" (cad les fichiers des
    VM en cours d'utilisation) est supporté.<br data-mce-bogus="1"></div><div>cf. https://www.cyberciti.biz/faq/how-to-create-create-snapshot-in-linux-kvm-vmdomain/<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>3/ Si je veux AUSSI que
    tout ça vive "sur" une architecture robuste distribuée, avec au moins deux serveurs capable de prendre le relais l'un de l'autre, comment faire ?<br data-mce-bogus="1"></div><div>Je ne parle pas de cluster HA avec corosync/heartbeat etc. qui requiert
    une faible latence qui impose que les deux noeuds soient à proximité pour être synchronisés.<br data-mce-bogus="1"></div><div>Je parle de deux serveurs distants, capables de prendre le relais l'un de l'autre qui flancherait.<br data-mce-bogus="1"></
    <div>Tout ça m'évoque des FS distribués que je connais mal ou pas. Mais il vaut mieux en parler avant qu'après ! Je crois que ce sont tout de même des préoccupations orthogonales puisqu'on doit pouvoir y faire tourner ce qu'on veut.<br data-
    mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Merci<br data-mce-bogus="1"></div><div>Cordialement<br data-mce-bogus="1"></div><div>Roger<br data-mce-bogus="1"></div></div></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sabri KHEMISSA@21:1/5 to All on Sun Jul 10 13:00:01 2022
    Bonjour,

    Je pense que Proxmox VE https://www.proxmox.com/en/proxmox-ve adressera une grande partie de tes besoins.
    - Virtualisation multiOS (LXC pour linux et KVM pour une full
    virtualisation)
    - L'ensemble des composants est packagé dans une unique plateforme maintenu par la communauté
    - Backups natifs
    - Capacité native de cluster (il faut creuser le sujet du cluster géographique) https://www.nextinpact.com/article/68503/promox-ve-creer-cluster-gerer-haute-disponibilite-et-migrations-live

    Concernant la fluidité avec des accès distants, tu peux toujours essayer de présenter tes vm dans une interface html5 via Apache Guacamole https://guacamole.apache.org/

    Concernant les services d'impression/scanner, je pense que le mieux est de passer en IP.

    Concernant les services de visioconf, il faut tester.

    Cordialement
    Sabri

    Le sam. 9 juil. 2022 à 19:27, <roger.tarani@free.fr> a écrit :

    Bonjour,

    Je vise le double objectif suivant :
    1/ permettre à des utilisateurs linux (CLI ou GUI) ou autre win (ou MacOS, mais ça coince un peu apparemment) d'accéder à leur machine devenue virtualisée sur un beau serveru linux ; depuis un poste quelconque muni du client idoine (ssh, x2go, vnc, rdp).
    2/ sauvegarder automatiquement ces machines en profitant des capacités de cette architecture (prendre des instantanés automatiques basés sur les blocs modifiés ; prendre un instantané ; restaurer une version d'instantané) ; là c'est un peu flou pour moi sauf que l'utilisateur doit pouvoir choisir ce qu'il veut récupérer (au niveau d'une VM) ou au niveau d'un FS à quoi il veut revenir à la manière de Deja Dup/Timeshift/Back in Time/etc., l'équivalent linux d'Apple TimeMachine ; ce qui me fait dire qu'il faut en connaître un peu plus pour pouvoir décider !

    Je pense à libvirt qemu/kvm que j'ai déjà expérimenté.
    J'avais peiné longtemps sur les pilotes (redhat, je crois) et n'ai jamais
    su si j'avais obtenu la performance maximale possible. Mais ça marchait.

    Questions
    1/ L'utilisateur va-t-il retrouver une fluidité indiscutable avec un
    réseau rapide (FO/ADSL) ? avec un réseau mobile (4G/3G) ?
    et les services habituels (dialoguer avec l'imprimante/le scanner local habituel, vidéoconf)

    2/ Comment assurer les tâches relatives au stockage (Sauvegarder/Synchroniser/Archiver) pour rendre robuste cette architecture ? A priori, sauvegarder "ça" (cad les fichiers des VM en cours
    d'utilisation) est supporté.
    cf. https://www.cyberciti.biz/faq/how-to-create-create-snapshot-in-linux-kvm-vmdomain/

    3/ Si je veux AUSSI que tout ça vive "sur" une architecture robuste distribuée, avec au moins deux serveurs capable de prendre le relais l'un
    de l'autre, comment faire ?
    Je ne parle pas de cluster HA avec corosync/heartbeat etc. qui requiert
    une faible latence qui impose que les deux noeuds soient à proximité pour être synchronisés.
    Je parle de deux serveurs distants, capables de prendre le relais l'un de l'autre qui flancherait.
    Tout ça m'évoque des FS distribués que je connais mal ou pas. Mais il vaut mieux en parler avant qu'après ! Je crois que ce sont tout de même des préoccupations orthogonales puisqu'on doit pouvoir y faire tourner ce qu'on veut.

    Merci
    Cordialement
    Roger


    <div dir="auto">Bonjour,<div dir="auto"><br></div><div dir="auto">Je pense que Proxmox VE <a href="https://www.proxmox.com/en/proxmox-ve">https://www.proxmox.com/en/proxmox-ve</a> adressera une grande partie de tes besoins.</div><div dir="auto">-
    Virtualisation multiOS (LXC pour linux et KVM pour une full virtualisation)</div><div dir="auto">- L&#39;ensemble des composants est packagé dans une unique plateforme maintenu par la communauté </div><div dir="auto">- Backups natifs</div><div dir="
    auto">- Capacité native de cluster (il faut creuser le sujet du cluster géographique)</div><div dir="auto"><a href="https://www.nextinpact.com/article/68503/promox-ve-creer-cluster-gerer-haute-disponibilite-et-migrations-live">https://www.nextinpact.
    com/article/68503/promox-ve-creer-cluster-gerer-haute-disponibilite-et-migrations-live</a><br></div><div dir="auto"><br></div><div dir="auto">Concernant la fluidité avec des accès distants, tu peux toujours essayer de présenter tes vm dans une
    interface html5 via Apache Guacamole <a href="https://guacamole.apache.org/">https://guacamole.apache.org/</a></div><div dir="auto"><br></div><div dir="auto">Concernant les services d&#39;impression/scanner, je pense que le mieux est de passer en IP.</
    <div dir="auto"><br></div><div dir="auto">Concernant les services de visioconf, il faut tester.</div><div dir="auto"><br></div><div dir="auto">Cordialement </div>Sabri<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Le
    sam. 9 juil. 2022 à 19:27, &lt;<a href="mailto:roger.tarani@free.fr">roger.tarani@free.fr</a>&gt; a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:
    arial,helvetica,sans-serif;font-size:12pt;color:#000000"><div>Bonjour,<br></div><div><br></div><div>Je vise le double objectif suivant :</div><div>1/ permettre à des utilisateurs linux (CLI ou GUI) ou autre win (ou MacOS, mais ça coince un peu
    apparemment) d&#39;accéder à leur machine devenue virtualisée sur un beau serveru linux ; depuis un poste quelconque muni du client idoine (ssh, x2go, vnc, rdp).<br></div><div>2/ sauvegarder automatiquement ces machines en profitant des capacités de
    cette architecture (prendre des instantanés automatiques basés sur les blocs modifiés ; prendre un instantané ; restaurer une version d&#39;instantané) ; là c&#39;est un peu flou pour moi sauf que l&#39;utilisateur doit pouvoir choisir ce qu&#39;il
    veut récupérer (au niveau d&#39;une VM) ou au niveau d&#39;un FS  à quoi il veut revenir à la manière de Deja Dup/Timeshift/Back in Time/etc., l&#39;équivalent linux d&#39;Apple TimeMachine ; ce qui me fait dire qu&#39;il faut en connaître un peu
    plus pour pouvoir décider !<br></div><div><br></div><div>Je pense à  libvirt qemu/kvm que j&#39;ai déjà expérimenté.</div><div>J&#39;avais peiné longtemps sur les pilotes (redhat, je crois) et n&#39;ai jamais su si j&#39;avais obtenu la
    performance maximale possible. Mais ça marchait.<br></div><div><br></div><div>Questions<br></div><div>1/ L&#39;utilisateur va-t-il retrouver une fluidité indiscutable avec un réseau rapide (FO/ADSL) ? avec un réseau mobile (4G/3G) ?<br></div><div>et
    les services habituels (dialoguer avec l&#39;imprimante/le scanner local habituel, vidéoconf)<br></div><div><br></div><div>2/ Comment assurer les tâches relatives au stockage (Sauvegarder/Synchroniser/Archiver) pour rendre robuste cette architecture ?</
    <div>A priori, sauvegarder &quot;ça&quot; (cad les fichiers des VM en cours d&#39;utilisation) est supporté.<br></div><div>cf. <a href="https://www.cyberciti.biz/faq/how-to-create-create-snapshot-in-linux-kvm-vmdomain/" target="_blank" rel="
    noreferrer">https://www.cyberciti.biz/faq/how-to-create-create-snapshot-in-linux-kvm-vmdomain/</a><br></div><div><br></div><div>3/ Si je veux AUSSI que tout ça vive &quot;sur&quot; une architecture robuste distribuée, avec au moins deux serveurs
    capable de prendre le relais l&#39;un de l&#39;autre, comment faire ?<br></div><div>Je ne parle pas de cluster HA avec corosync/heartbeat etc. qui requiert une faible latence qui impose que les deux noeuds soient à proximité pour être synchronisés.<
    </div><div>Je parle de deux serveurs distants, capables de prendre le relais l&#39;un de l&#39;autre qui flancherait.<br></div><div>Tout ça m&#39;évoque des FS distribués que je connais mal ou pas. Mais il vaut mieux en parler avant qu&#39;après !
    Je crois que ce sont tout de même des préoccupations orthogonales puisqu&#39;on doit pouvoir y faire tourner ce qu&#39;on veut.<br></div><div><br></div><div>Merci<br></div><div>Cordialement<br></div><div>Roger<br></div></div></div></blockquote></div></


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From roger.tarani@free.fr@21:1/5 to All on Sun Jul 10 15:40:01 2022
    De: "Sabri KHEMISSA" <sabri.khemissa@gmail.com>
    À: "roger tarani" <roger.tarani@free.fr>
    Cc: "Liste Debian" <debian-user-french@lists.debian.org>
    Envoyé: Dimanche 10 Juillet 2022 12:52:01
    Objet: Re: Virtualisation distribuée de machines (avec différents OS)


    Bonjour,

    Je pense que Proxmox VE [ https://www.proxmox.com/en/proxmox-ve | https://www.proxmox.com/en/proxmox-ve ] adressera une grande partie de tes besoins.
    - Virtualisation multiOS (LXC pour linux et KVM pour une full virtualisation) - L'ensemble des composants est packagé dans une unique plateforme maintenu par la communauté
    - Backups natifs
    - Capacité native de cluster (il faut creuser le sujet du cluster géographique)

    Merci.
    A ma connaissance, proxmox est une solution de HA cluster où il faut au moins deux noeuds reliés avec une faible latence, cad dans le même lieu et pas très éloignés (moins de 10- 20 de câble, de vague mémoire).
    Si je veux atteindre l'objectif d'un cluster distribué géographiquement, (cad : latence > 100 ms ou beaucoup plus), je ne crois pas que proxmox le permette, si ?

    Merci
    cordialement


    Le sam. 9 juil. 2022 à 19:27, < [ mailto:roger.tarani@free.fr | roger.tarani@free.fr ] > a écrit :



    Bonjour,

    Je vise le double objectif suivant :
    1/ permettre à des utilisateurs linux (CLI ou GUI) ou autre win (ou MacOS, mais ça coince un peu apparemment) d'accéder à leur machine devenue virtualisée sur un beau serveru linux ; depuis un poste quelconque muni du client idoine (ssh, x2go, vnc,
    rdp).
    2/ sauvegarder automatiquement ces machines en profitant des capacités de cette architecture (prendre des instantanés automatiques basés sur les blocs modifiés ; prendre un instantané ; restaurer une version d'instantané) ; là c'est un peu flou
    pour moi sauf que l'utilisateur doit pouvoir choisir ce qu'il veut récupérer (au niveau d'une VM) ou au niveau d'un FS à quoi il veut revenir à la manière de Deja Dup/Timeshift/Back in Time/etc., l'équivalent linux d'Apple TimeMachine ; ce qui me
    fait dire qu'il faut en connaître un peu plus pour pouvoir décider !

    Je pense à libvirt qemu/kvm que j'ai déjà expérimenté.
    J'avais peiné longtemps sur les pilotes (redhat, je crois) et n'ai jamais su si j'avais obtenu la performance maximale possible. Mais ça marchait.

    Questions
    1/ L'utilisateur va-t-il retrouver une fluidité indiscutable avec un réseau rapide (FO/ADSL) ? avec un réseau mobile (4G/3G) ?
    et les services habituels (dialoguer avec l'imprimante/le scanner local habituel, vidéoconf)

    2/ Comment assurer les tâches relatives au stockage (Sauvegarder/Synchroniser/Archiver) pour rendre robuste cette architecture ?
    A priori, sauvegarder "ça" (cad les fichiers des VM en cours d'utilisation) est supporté.
    cf. [ https://www.cyberciti.biz/faq/how-to-create-create-snapshot-in-linux-kvm-vmdomain/ | https://www.cyberciti.biz/faq/how-to-create-create-snapshot-in-linux-kvm-vmdomain/ ]

    3/ Si je veux AUSSI que tout ça vive "sur" une architecture robuste distribuée, avec au moins deux serveurs capable de prendre le relais l'un de l'autre, comment faire ?
    Je ne parle pas de cluster HA avec corosync/heartbeat etc. qui requiert une faible latence qui impose que les deux noeuds soient à proximité pour être synchronisés.
    Je parle de deux serveurs distants, capables de prendre le relais l'un de l'autre qui flancherait.
    Tout ça m'évoque des FS distribués que je connais mal ou pas. Mais il vaut mieux en parler avant qu'après ! Je crois que ce sont tout de même des préoccupations orthogonales puisqu'on doit pouvoir y faire tourner ce qu'on veut.

    Merci
    Cordialement
    Roger





    <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div><br data-mce-bogus="1"></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><b>De: </b>"Sabri KHEMISSA" &lt;sabri.khemissa@
    gmail.com&gt;<br><b>À: </b>"roger tarani" &lt;roger.tarani@free.fr&gt;<br><b>Cc: </b>"Liste Debian" &lt;debian-user-french@lists.debian.org&gt;<br><b>Envoyé: </b>Dimanche 10 Juillet 2022 12:52:01<br><b>Objet: </b>Re: Virtualisation distribuée de
    machines (avec différents OS)<br></div><div><br data-mce-bogus="1"></div><div dir="auto"><div><br></div><div data-marker="__QUOTED_TEXT__"><div dir="auto">Bonjour,</div></div><br><div dir="auto" style="padding-left: 30px;" data-mce-style="padding-left:
    30px;"><span style="font-family: times new roman, new york, times, serif;" data-mce-style="font-family: times new roman, new york, times, serif;">Je pense que Proxmox VE <a href="https://www.proxmox.com/en/proxmox-ve" target="_blank" rel="nofollow
    noopener noreferrer">https://www.proxmox.com/en/proxmox-ve</a> adressera une grande partie de tes besoins.</span></div><div dir="auto" style="padding-left: 30px;" data-mce-style="padding-left: 30px;"><span style="font-family: times new roman, new york,
    times, serif;" data-mce-style="font-family: times new roman, new york, times, serif;">- Virtualisation multiOS (LXC pour linux et KVM pour une full virtualisation)</span></div><div dir="auto" style="padding-left: 30px;" data-mce-style="padding-left: 30px;
    "><span style="font-family: times new roman, new york, times, serif;" data-mce-style="font-family: times new roman, new york, times, serif;">- L'ensemble des composants est packagé dans une unique plateforme maintenu par la communauté&nbsp;</span></div>
    <div dir="auto" style="padding-left: 30px;" data-mce-style="padding-left: 30px;"><span style="font-family: times new roman, new york, times, serif;" data-mce-style="font-family: times new roman, new york, times, serif;">- Backups natifs</span></div><div
    dir="auto" style="padding-left: 30px;" data-mce-style="padding-left: 30px;"><span style="font-family: times new roman, new york, times, serif;" data-mce-style="font-family: times new roman, new york, times, serif;">- Capacité native de cluster (il faut
    creuser le sujet du cluster géographique)</span></div><div dir="auto" style="padding-left: 30px;" data-mce-style="padding-left: 30px;"><br data-mce-bogus="1"></div></div><div data-marker="__QUOTED_TEXT__"><div dir="auto"><div>Merci.</div><div>A ma
    connaissance, proxmox est une solution de HA cluster où il faut au moins deux noeuds reliés avec une faible latence, cad dans le même lieu et pas très éloignés (moins de 10- 20 de câble, de vague mémoire).<br></div><div>Si je veux atteindre l'
    objectif d'un cluster distribué géographiquement, (cad : latence &gt; 100 ms ou beaucoup plus), je ne crois pas que proxmox le permette, si ?<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Merci</div><div>cordialement<br data-mce-
    bogus="1"></div><div><br data-mce-bogus="1"></div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Le sam. 9 juil. 2022 à 19:27, &lt;<a href="mailto:roger.tarani@free.fr" target="_blank" rel="nofollow noopener noreferrer">roger.
    tarani@free.fr</a>&gt; a écrit&nbsp;:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:'arial' , 'helvetica' , sans-serif;font-size:12pt;color:#000000"><div>
    Bonjour,<br></div><br><div>Je vise le double objectif suivant :</div><div>1/ permettre à des utilisateurs linux (CLI ou GUI) ou autre win (ou MacOS, mais ça coince un peu apparemment) d'accéder à leur machine devenue virtualisée sur un beau serveru
    linux ; depuis un poste quelconque muni du client idoine (ssh, x2go, vnc, rdp).<br></div><div>2/ sauvegarder automatiquement ces machines en profitant des capacités de cette architecture (prendre des instantanés automatiques basés sur les blocs modifiÃ
    ©s ; prendre un instantané ; restaurer une version d'instantané) ; là c'est un peu flou pour moi sauf que l'utilisateur doit pouvoir choisir ce qu'il veut récupérer (au niveau d'une VM) ou au niveau d'un FS&nbsp; à quoi il veut revenir à la maniè
    re de Deja Dup/Timeshift/Back in Time/etc., l'équivalent linux d'Apple TimeMachine ; ce qui me fait dire qu'il faut en connaître un peu plus pour pouvoir décider !<br></div><br><div>Je pense à&nbsp; libvirt qemu/kvm que j'ai déjà expérimenté.</
    <div>J'avais peiné longtemps sur les pilotes (redhat, je crois) et n'ai jamais su si j'avais obtenu la performance maximale possible. Mais ça marchait.<br></div><br><div>Questions<br></div><div>1/ L'utilisateur va-t-il retrouver une fluidité
    indiscutable avec un réseau rapide (FO/ADSL) ? avec un réseau mobile (4G/3G) ?<br></div><div>et les services habituels (dialoguer avec l'imprimante/le scanner local habituel, vidéoconf)<br></div><br><div>2/ Comment assurer les tâches relatives au
    stockage (Sauvegarder/Synchroniser/Archiver) pour rendre robuste cette architecture ?</div><div>A priori, sauvegarder "ça" (cad les fichiers des VM en cours d'utilisation) est supporté.<br></div><div>cf. <a href="https://www.cyberciti.biz/faq/how-to-
    create-create-snapshot-in-linux-kvm-vmdomain/" rel="noreferrer nofollow noopener noreferrer" target="_blank">https://www.cyberciti.biz/faq/how-to-create-create-snapshot-in-linux-kvm-vmdomain/</a><br></div><br><div>3/ Si je veux AUSSI que tout ça vive "
    sur" une architecture robuste distribuée, avec au moins deux serveurs capable de prendre le relais l'un de l'autre, comment faire ?<br></div><div>Je ne parle pas de cluster HA avec corosync/heartbeat etc. qui requiert une faible latence qui impose que
    les deux noeuds soient à proximité pour être synchronisés.<br></div><div>Je parle de deux serveurs distants, capables de prendre le relais l'un de l'autre qui flancherait.<br></div><div>Tout ça m'évoque des FS distribués que je connais mal ou pas.
    Mais il vaut mieux en parler avant qu'après ! Je crois que ce sont tout de même des préoccupations orthogonales puisqu'on doit pouvoir y faire tourner ce qu'on veut.<br></div><br><div>Merci<br></div><div>Cordialement<br></div><div>Roger</div></div></
    </blockquote></div></div><br></div></div></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hugues Larrive@21:1/5 to All on Sun Jul 10 20:30:01 2022
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------040896351af4fb1df2c463dcf5321d3b
    Content-Type: multipart/alternative;boundary=---------------------a9df3899cd43996eda7a81d6d50ca2ed

    -----------------------a9df3899cd43996eda7a81d6d50ca2ed Content-Transfer-Encoding: quoted-printable
    Content-Type: text/plain;charset=utf-8

    Bonjour,



    ------- Original Message -------
    Le dimanche 10 juillet 2022 à 15:32, <roger.tarani@free.fr> a écrit :






    De: "Sabri KHEMISSA" <sabri.khemissa@gmail.com>
    À: "roger tarani" <roger.tarani@free.fr>
    Cc: "Liste Debian" <debian-user-french@lists.debian.org>
    Envoyé: Dimanche 10 Juillet 2022 12:52:01
    Objet: Re: Virtualisation distribuée de machines (avec différents OS)




    Bonjour,


    Je pense que Proxmox VE https://www.proxmox.com/en/proxmox-ve adressera une grande partie de tes besoins.
    - Virtualisation multiOS (LXC pour linux et KVM pour une full virtualisation) - L'ensemble des composants est packagé dans une unique plateforme maintenu par la communauté 
    - Backups natifs
    - Capacité native de cluster (il faut creuser le sujet du cluster géographique)


    Merci.
    A ma connaissance, proxmox est une solution de HA cluster où il faut au moins deux noeuds reliés avec une faible latence, cad dans le même lieu et pas très éloignés (moins de 10- 20 de câble, de vague mémoire).
    Si je veux atteindre l'objectif d'un cluster distribué géographiquement, (cad : latence > 100 ms ou beaucoup plus), je ne crois pas que proxmox le permette, si ?


    Je pense que si, avec DRBD en mode asynchrone...




    Merci
    cordialement




    Le sam. 9 juil. 2022 à 19:27, <roger.tarani@free.fr> a écrit :


    Bonjour,


    Je vise le double objectif suivant :
    1/ permettre à des utilisateurs linux (CLI ou GUI) ou autre win (ou MacOS, mais ça coince un peu apparemment) d'accéder à leur machine devenue virtualisée sur un beau serveru linux ; depuis un poste quelconque muni du client idoine (ssh, x2go,
    vnc, rdp).
    2/ sauvegarder automatiquement ces machines en profitant des capacités de cette architecture (prendre des instantanés automatiques basés sur les blocs modifiés ; prendre un instantané ; restaurer une version d'instantané) ; là c'est un peu
    flou pour moi sauf que l'utilisateur doit pouvoir choisir ce qu'il veut récupérer (au niveau d'une VM) ou au niveau d'un FS  à quoi il veut revenir à la manière de Deja Dup/Timeshift/Back in Time/etc., l'équivalent linux d'Apple TimeMachine ; ce
    qui me fait dire qu'il faut en connaître un peu plus pour pouvoir décider !


    Je pense à  libvirt qemu/kvm que j'ai déjà expérimenté.
    J'avais peiné longtemps sur les pilotes (redhat, je crois) et n'ai jamais su si j'avais obtenu la performance maximale possible. Mais ça marchait.


    Questions
    1/ L'utilisateur va-t-il retrouver une fluidité indiscutable avec un réseau rapide (FO/ADSL) ? avec un réseau mobile (4G/3G) ?
    et les services habituels (dialoguer avec l'imprimante/le scanner local habituel, vidéoconf)


    2/ Comment assurer les tâches relatives au stockage (Sauvegarder/Synchroniser/Archiver) pour rendre robuste cette architecture ?
    A priori, sauvegarder "ça" (cad les fichiers des VM en cours d'utilisation) est supporté.
    cf. https://www.cyberciti.biz/faq/how-to-create-create-snapshot-in-linux-kvm-vmdomain/


    3/ Si je veux AUSSI que tout ça vive "sur" une architecture robuste distribuée, avec au moins deux serveurs capable de prendre le relais l'un de l'autre, comment faire ?
    Je ne parle pas de cluster HA avec corosync/heartbeat etc. qui requiert une faible latence qui impose que les deux noeuds soient à proximité pour être synchronisés.
    Je parle de deux serveurs distants, capables de prendre le relais l'un de l'autre qui flancherait.
    Tout ça m'évoque des FS distribués que je connais mal ou pas. Mais il vaut mieux en parler avant qu'après ! Je crois que ce sont tout de même des préoccupations orthogonales puisqu'on doit pouvoir y faire tourner ce qu'on veut.


    Merci
    Cordialement
    Roger
    -----------------------a9df3899cd43996eda7a81d6d50ca2ed
    Content-Type: multipart/related;boundary=---------------------b3569cf71e46b3c9ccda2b80bd2aea0f

    -----------------------b3569cf71e46b3c9ccda2b80bd2aea0f
    Content-Type: text/html;charset=utf-8
    Content-Transfer-Encoding: base64

    PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7Ij5Cb25qb3Vy LDwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgZm9udC1zaXplOiAxNHB4OyI+ PGJyPjwvZGl2Pgo8ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jayBwcm90b25t YWlsX3NpZ25hdHVyZV9ibG9jay1lbXB0eSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbDsgZm9u dC1zaXplOiAxNHB4OyI+CiAgICA8ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9j ay11c2VyIHByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLWVtcHR5Ij4KICAgICAgICAKICAgICAg ICAgICAgPC9kaXY+CiAgICAKICAgICAgICAgICAgPGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWdu YXR1cmVfYmxvY2stcHJvdG9uIHByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLWVtcHR5Ij4KICAg ICAgICAKICAgICAgICAgICAgPC9kaXY+CjwvZGl2Pgo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTog QXJpYWw7IGZvbnQtc2l6ZTogMTRweDsiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWls X3F1b3RlIj4KICAgICAgICAtLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLTxicj4KICAg ICAgICBMZSBkaW1hbmNoZSAxMCBqdWlsbGV0IDIwMjIgw6AgMTU6MzIsICAmbHQ7cm9nZXIudGFy YW5pQGZyZWUuZnImZ3Q7IGEgw6ljcml0IDo8YnI+PGJyPgogICAgICAgIDxibG9ja3F1b3RlIGNs YXNzPSJwcm90b25tYWlsX3F1b3RlIiB0eXBlPSJjaXRlIj4KICAgICAgICAgICAgPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IGFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTJwdDsgY29sb3I6ICMwMDAwMDAiPjxkaXY+PGJyIGRhdGEtbWNlLWJvZ3VzPSIxIj48L2Rpdj48 aHIgZGF0YS1tYXJrZXI9Il9fRElWSURFUl9fIiBpZD0iendjaHIiPjxkaXYgZGF0YS1tYXJrZXI9 Il9fSEVBREVSU19fIj48Yj5EZTogPC9iPiJTYWJyaSBLSEVNSVNTQSIgJmx0O3NhYnJpLmtoZW1p c3NhQGdtYWlsLmNvbSZndDs8YnI+PGI+w4A6IDwvYj4icm9nZXIgdGFyYW5pIiAmbHQ7cm9nZXIu dGFyYW5pQGZyZWUuZnImZ3Q7PGJyPjxiPkNjOiA8L2I+Ikxpc3RlIERlYmlhbiIgJmx0O2RlYmlh bi11c2VyLWZyZW5jaEBsaXN0cy5kZWJpYW4ub3JnJmd0Ozxicj48Yj5FbnZvecOpOiA8L2I+RGlt YW5jaGUgMTAgSnVpbGxldCAyMDIyIDEyOjUyOjAxPGJyPjxiPk9iamV0OiA8L2I+UmU6IFZpcnR1 YWxpc2F0aW9uIGRpc3RyaWJ1w6llIGRlIG1hY2hpbmVzIChhdmVjIGRpZmbDqXJlbnRzIE9TKTxi cj48L2Rpdj48ZGl2PjxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9kaXY+PGRpdiBkaXI9ImF1dG8i PjxkaXY+PGJyPjwvZGl2PjxkaXYgZGF0YS1tYXJrZXI9Il9fUVVPVEVEX1RFWFRfXyI+PGRpdiBk aXI9ImF1dG8iPkJvbmpvdXIsPC9kaXY+PC9kaXY+PGJyPjxkaXYgZGF0YS1tY2Utc3R5bGU9InBh ZGRpbmctbGVmdDogMzBweDsiIHN0eWxlPSJwYWRkaW5nLWxlZnQ6IDMwcHg7IiBkaXI9ImF1dG8i PjxzcGFuIGRhdGEtbWNlLXN0eWxlPSJmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLCBuZXcg eW9yaywgdGltZXMsIHNlcmlmOyIgc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4s IG5ldyB5b3JrLCB0aW1lcywgc2VyaWY7Ij5KZSBwZW5zZSBxdWUgUHJveG1veCBWRSA8YSByZWw9 Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIHRhcmdldD0iX2JsYW5rIiBocmVmPSJodHRw czovL3d3dy5wcm94bW94LmNvbS9lbi9wcm94bW94LXZlIj5odHRwczovL3d3dy5wcm94bW94LmNv bS9lbi9wcm94bW94LXZlPC9hPiBhZHJlc3NlcmEgdW5lIGdyYW5kZSBwYXJ0aWUgZGUgdGVzIGJl c29pbnMuPC9zcGFuPjwvZGl2PjxkaXYgZGF0YS1tY2Utc3R5bGU9InBhZGRpbmctbGVmdDogMzBw eDsiIHN0eWxlPSJwYWRkaW5nLWxlZnQ6IDMwcHg7IiBkaXI9ImF1dG8iPjxzcGFuIGRhdGEtbWNl LXN0eWxlPSJmb250LWZhbWlseTogdGltZXMgbmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNl cmlmOyIgc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1l cywgc2VyaWY7Ij4tIFZpcnR1YWxpc2F0aW9uIG11bHRpT1MgKExYQyBwb3VyIGxpbnV4IGV0IEtW TSBwb3VyIHVuZSBmdWxsIHZpcnR1YWxpc2F0aW9uKTwvc3Bhbj48L2Rpdj48ZGl2IGRhdGEtbWNl LXN0eWxlPSJwYWRkaW5nLWxlZnQ6IDMwcHg7IiBzdHlsZT0icGFkZGluZy1sZWZ0OiAzMHB4OyIg ZGlyPSJhdXRvIj48c3BhbiBkYXRhLW1jZS1zdHlsZT0iZm9udC1mYW1pbHk6IHRpbWVzIG5ldyBy b21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZjsiIHN0eWxlPSJmb250LWZhbWlseTogdGltZXMg bmV3IHJvbWFuLCBuZXcgeW9yaywgdGltZXMsIHNlcmlmOyI+LSBMJ2Vuc2VtYmxlIGRlcyBjb21w b3NhbnRzIGVzdCBwYWNrYWfDqSBkYW5zIHVuZSB1bmlxdWUgcGxhdGVmb3JtZSBtYWludGVudSBw YXIgbGEgY29tbXVuYXV0w6kmbmJzcDs8L3NwYW4+PC9kaXY+PGRpdiBkYXRhLW1jZS1zdHlsZT0i cGFkZGluZy1sZWZ0OiAzMHB4OyIgc3R5bGU9InBhZGRpbmctbGVmdDogMzBweDsiIGRpcj0iYXV0 byI+PHNwYW4gZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5OiB0aW1lcyBuZXcgcm9tYW4sIG5l dyB5b3JrLCB0aW1lcywgc2VyaWY7IiBzdHlsZT0iZm9udC1mYW1pbHk6IHRpbWVzIG5ldyByb21h biwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZjsiPi0gQmFja3VwcyBuYXRpZnM8L3NwYW4+PC9kaXY+ PGRpdiBkYXRhLW1jZS1zdHlsZT0icGFkZGluZy1sZWZ0OiAzMHB4OyIgc3R5bGU9InBhZGRpbmct bGVmdDogMzBweDsiIGRpcj0iYXV0byI+PHNwYW4gZGF0YS1tY2Utc3R5bGU9ImZvbnQtZmFtaWx5 OiB0aW1lcyBuZXcgcm9tYW4sIG5ldyB5b3JrLCB0aW1lcywgc2VyaWY7IiBzdHlsZT0iZm9udC1m YW1pbHk6IHRpbWVzIG5ldyByb21hbiwgbmV3IHlvcmssIHRpbWVzLCBzZXJpZjsiPi0gQ2FwYWNp dMOpIG5hdGl2ZSBkZSBjbHVzdGVyIChpbCBmYXV0IGNyZXVzZXIgbGUgc3VqZXQgZHUgY2x1c3Rl ciBnw6lvZ3JhcGhpcXVlKTwvc3Bhbj48L2Rpdj48ZGl2IGRhdGEtbWNlLXN0eWxlPSJwYWRkaW5n LWxlZnQ6IDMwcHg7IiBzdHlsZT0icGFkZGluZy1sZWZ0OiAzMHB4OyIgZGlyPSJhdXRvIj48YnIg ZGF0YS1tY2UtYm9ndXM9IjEiPjwvZGl2PjwvZGl2PjxkaXYgZGF0YS1tYXJrZXI9Il9fUVVPVEVE X1RFWFRfXyI+PGRpdiBkaXI9ImF1dG8iPjxkaXY+TWVyY2kuPC9kaXY+PGRpdj5BIG1hIGNvbm5h aXNzYW5jZSwgcHJveG1veCBlc3QgdW5lIHNvbHV0aW9uIGRlIEhBIGNsdXN0ZXIgb8O5IGlsIGZh dXQgYXUgbW9pbnMgZGV1eCBub2V1ZHMgcmVsacOpcyBhdmVjIHVuZSBmYWlibGUgbGF0ZW5jZSwg Y2FkIGRhbnMgbGUgbcOqbWUgbGlldSBldCBwYXMgdHLDqHMgw6lsb2lnbsOpcyAobW9pbnMgZGUg MTAtIDIwIGRlIGPDomJsZSwgZGUgdmFndWUgbcOpbW9pcmUpLjxicj48L2Rpdj48ZGl2PlNpIGpl IHZldXggYXR0ZWluZHJlIGwnb2JqZWN0aWYgZCd1biBjbHVzdGVyIGRpc3RyaWJ1w6kgZ8Opb2dy YXBoaXF1ZW1lbnQsIChjYWQgOiBsYXRlbmNlICZndDsgMTAwIG1zIG91IGJlYXVjb3VwIHBsdXMp LCBqZSBuZSBjcm9pcyBwYXMgcXVlIHByb3htb3ggbGUgcGVybWV0dGUsIHNpID88L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs OyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7Ij48YnI+PC9kaXY+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGNvbG9yOiByZ2Io MzQsIDM0LCAzNCk7Ij5KZSBwZW5zZSBxdWUgc2ksIGF2ZWMgRFJCRCBlbiBtb2RlIGFzeW5jaHJv bmUuLi48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6 IDE0cHg7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7Ij48YnIgZGF0YS1tY2UtYm9ndXM9IjEiPjwv ZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIiB0eXBlPSJjaXRlIj48ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxMnB0OyBjb2xvcjogIzAwMDAwMCI+PGRpdiBkYXRhLW1hcmtlcj0iX19RVU9URURfVEVY VF9fIj48ZGl2IGRpcj0iYXV0byI+PGRpdj48YnIgZGF0YS1tY2UtYm9ndXM9IjEiPjwvZGl2Pjxk aXY+TWVyY2k8L2Rpdj48ZGl2PmNvcmRpYWxlbWVudDxiciBkYXRhLW1jZS1ib2d1cz0iMSI+PC9k aXY+PGRpdj48YnIgZGF0YS1tY2UtYm9ndXM9IjEiPjwvZGl2Pjxicj48ZGl2IGRpcj0iYXV0byIg Y2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGNsYXNzPSJnbWFpbF9hdHRyIiBkaXI9Imx0ciI+TGUg c2FtLiA5IGp1aWwuIDIwMjIgw6AgMTk6MjcsICAmbHQ7PGEgcmVsPSJub3JlZmVycmVyIG5vZm9s bG93IG5vb3BlbmVyIiB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOnJvZ2VyLnRhcmFuaUBm cmVlLmZyIj5yb2dlci50YXJhbmlAZnJlZS5mcjwvYT4mZ3Q7IGEgw6ljcml0Jm5ic3A7Ojxicj48 L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAgMCAwIDAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTonYXJpYWwnICwgJ2hlbHZldGljYScgLCBzYW5zLXNlcmlm O2ZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDAiPjxkaXY+Qm9uam91ciw8YnI+PC9kaXY+PGJy PjxkaXY+SmUgdmlzZSBsZSBkb3VibGUgb2JqZWN0aWYgc3VpdmFudCA6PC9kaXY+PGRpdj4xLyBw ZXJtZXR0cmUgw6AgZGVzIHV0aWxpc2F0ZXVycyBsaW51eCAoQ0xJIG91IEdVSSkgb3UgYXV0cmUg d2luIChvdSBNYWNPUywgbWFpcyDDp2EgY29pbmNlIHVuIHBldSBhcHBhcmVtbWVudCkgZCdhY2PD qWRlciDDoCBsZXVyIG1hY2hpbmUgZGV2ZW51ZSB2aXJ0dWFsaXPDqWUgc3VyIHVuIGJlYXUgc2Vy dmVydSBsaW51eCA7IGRlcHVpcyB1biBwb3N0ZSBxdWVsY29ucXVlIG11bmkgZHUgY2xpZW50IGlk b2luZSAoc3NoLCB4MmdvLCB2bmMsIHJkcCkuPGJyPjwvZGl2PjxkaXY+Mi8gc2F1dmVnYXJkZXIg YXV0b21hdGlxdWVtZW50IGNlcyBtYWNoaW5lcyBlbiBwcm9maXRhbnQgZGVzIGNhcGFjaXTDqXMg ZGUgY2V0dGUgYXJjaGl0ZWN0dXJlIChwcmVuZHJlIGRlcyBpbnN0YW50YW7DqXMgYXV0b21hdGlx dWVzIGJhc8OpcyBzdXIgbGVzIGJsb2NzIG1vZGlmacOpcyA7IHByZW5kcmUgdW4gaW5zdGFudGFu w6kgOyByZXN0YXVyZXIgdW5lIHZlcnNpb24gZCdpbnN0YW50YW7DqSkgOyBsw6AgYydlc3QgdW4g cGV1IGZsb3UgcG91ciBtb2kgc2F1ZiBxdWUgbCd1dGlsaXNhdGV1ciBkb2l0IHBvdXZvaXIgY2hv aXNpciBjZSBxdSdpbCB2ZXV0IHLDqWN1cMOpcmVyIChhdSBuaXZlYXUgZCd1bmUgVk0pIG91IGF1 IG5pdmVhdSBkJ3VuIEZTJm5ic3A7IMOgIHF1b2kgaWwgdmV1dCByZXZlbmlyIMOgIGxhIG1hbmnD qHJlIGRlIERlamEgRHVwL1RpbWVzaGlmdC9CYWNrIGluIFRpbWUvZXRjLiwgbCfDqXF1aXZhbGVu dCBsaW51eCBkJ0FwcGxlIFRpbWVNYWNoaW5lIDsgY2UgcXVpIG1lIGZhaXQgZGlyZSBxdSdpbCBm YXV0IGVuIGNvbm5hw650cmUgdW4gcGV1IHBsdXMgcG91ciBwb3V2b2lyIGTDqWNpZGVyICE8YnI+ PC9kaXY+PGJyPjxkaXY+SmUgcGVuc2Ugw6AmbmJzcDsgbGlidmlydCBxZW11L2t2bSBxdWUgaidh aSBkw6lqw6AgZXhww6lyaW1lbnTDqS48L2Rpdj48ZGl2PkonYXZhaXMgcGVpbsOpIGxvbmd0ZW1w cyBzdXIgbGVzIHBpbG90ZXMgKHJlZGhhdCwgamUgY3JvaXMpIGV0IG4nYWkgamFtYWlzIHN1IHNp IGonYXZhaXMgb2J0ZW51IGxhIHBlcmZvcm1hbmNlIG1heGltYWxlIHBvc3NpYmxlLiBNYWlzIMOn YSBtYXJjaGFpdC48YnI+PC9kaXY+PGJyPjxkaXY+UXVlc3Rpb25zPGJyPjwvZGl2PjxkaXY+MS8g TCd1dGlsaXNhdGV1ciB2YS10LWlsIHJldHJvdXZlciB1bmUgZmx1aWRpdMOpIGluZGlzY3V0YWJs ZSBhdmVjIHVuIHLDqXNlYXUgcmFwaWRlIChGTy9BRFNMKSA/IGF2ZWMgdW4gcsOpc2VhdSBtb2Jp bGUgKDRHLzNHKSA/PGJyPjwvZGl2PjxkaXY+ZXQgbGVzIHNlcnZpY2VzIGhhYml0dWVscyAoZGlh bG9ndWVyIGF2ZWMgbCdpbXByaW1hbnRlL2xlIHNjYW5uZXIgbG9jYWwgaGFiaXR1ZWwsIHZpZMOp b2NvbmYpPGJyPjwvZGl2Pjxicj48ZGl2PjIvIENvbW1lbnQgYXNzdXJlciBsZXMgdMOiY2hlcyBy ZWxhdGl2ZXMgYXUgc3RvY2thZ2UgKFNhdXZlZ2FyZGVyL1N5bmNocm9uaXNlci9BcmNoaXZlcikg cG91ciByZW5kcmUgcm9idXN0ZSBjZXR0ZSBhcmNoaXRlY3R1cmUgPzwvZGl2PjxkaXY+QSBwcmlv cmksIHNhdXZlZ2FyZGVyICLDp2EiIChjYWQgbGVzIGZpY2hpZXJzIGRlcyBWTSBlbiBjb3VycyBk J3V0aWxpc2F0aW9uKSBlc3Qgc3VwcG9ydMOpLjxicj48L2Rpdj48ZGl2PmNmLiA8YSB0YXJnZXQ9 Il9ibGFuayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiBocmVmPSJodHRwczov L3d3dy5jeWJlcmNpdGkuYml6L2ZhcS9ob3ctdG8tY3JlYXRlLWNyZWF0ZS1zbmFwc2hvdC1pbi1s aW51eC1rdm0tdm1kb21haW4vIj5odHRwczovL3d3dy5jeWJlcmNpdGkuYml6L2ZhcS9ob3ctdG8t Y3JlYXRlLWNyZWF0ZS1zbmFwc2hvdC1pbi1saW51eC1rdm0tdm1kb21haW4vPC9hPjxicj48L2Rp dj48YnI+PGRpdj4zLyBTaSBqZSB2ZXV4IEFVU1NJIHF1ZSB0b3V0IMOnYSB2aXZlICJzdXIiIHVu ZSBhcmNoaXRlY3R1cmUgcm9idXN0ZSBkaXN0cmlidcOpZSwgYXZlYyBhdSBtb2lucyBkZXV4IHNl cnZldXJzIGNhcGFibGUgZGUgcHJlbmRyZSBsZSByZWxhaXMgbCd1biBkZSBsJ2F1dHJlLCBjb21t ZW50IGZhaXJlID88YnI+PC9kaXY+PGRpdj5KZSBuZSBwYXJsZSBwYXMgZGUgY2x1c3RlciBIQSBh dmVjIGNvcm9zeW5jL2hlYXJ0YmVhdCBldGMuIHF1aSByZXF1aWVydCB1bmUgZmFpYmxlIGxhdGVu Y2UgcXVpIGltcG9zZSBxdWUgbGVzIGRldXggbm9ldWRzIHNvaWVudCDDoCBwcm94aW1pdMOpIHBv dXIgw6p0cmUgc3luY2hyb25pc8Opcy48YnI+PC9kaXY+PGRpdj5KZSBwYXJsZSBkZSBkZXV4IHNl cnZldXJzIGRpc3RhbnRzLCBjYXBhYmxlcyBkZSBwcmVuZHJlIGxlIHJlbGFpcyBsJ3VuIGRlIGwn YXV0cmUgcXVpIGZsYW5jaGVyYWl0Ljxicj48L2Rpdj48ZGl2PlRvdXQgw6dhIG0nw6l2b3F1ZSBk ZXMgRlMgZGlzdHJpYnXDqXMgcXVlIGplIGNvbm5haXMgbWFsIG91IHBhcy4gTWFpcyBpbCB2YXV0 IG1pZXV4IGVuIHBhcmxlciBhdmFudCBxdSdhcHLDqHMgISBKZSBjcm9pcyBxdWUgY2Ugc29udCB0 b3V0IGRlIG3Dqm1lIGRlcyBwcsOpb2NjdXBhdGlvbnMgb3J0aG9nb25hbGVzIHB1aXNxdSdvbiBk b2l0IHBvdXZvaXIgIHkgZmFpcmUgdG91cm5lciBjZSBxdSdvbiB2ZXV0Ljxicj48L2Rpdj48YnI+ PGRpdj5NZXJjaTxicj48L2Rpdj48ZGl2PkNvcmRpYWxlbWVudDxicj48L2Rpdj48ZGl2PlJvZ2Vy PC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2Pjxicj48L2Rpdj48L2Rp dj4KICAgICAgICA8L2Jsb2NrcXVvdGU+PGJyPgogICAgPC9kaXY+ -----------------------b3569cf71e46b3c9ccda2b80bd2aea0f-- -----------------------a9df3899cd43996eda7a81d6d50ca2ed-- -----------------------040896351af4fb1df2c463dcf5321d3b
    Content-Type: application/pgp-keys; filename="publickey - hlarrive@pm.me - 0xE9429B87.asc"; name="publickey - hlarrive@pm.me - 0xE9429B87.asc"
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename="publickey - hlarrive@pm.me - 0xE9429B87.asc"; name="publickey - hlarrive@pm.me - 0xE9429B87.asc"

    LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQpWZXJzaW9uOiBPcGVuUEdQLmpz IHY0LjEwLjEwDQpDb21tZW50OiBodHRwczovL29wZW5wZ3Bqcy5vcmcNCg0KeGpNRVlGRTFjUllK S3dZQkJBSGFSdzhCQVFkQVpQdDNnYXpDa3R1c2lxZWtoM3JzbDNBS1dJVGlEdVRhDQpaT21kSEJa MG1vek5IMmhzWVhKeWFYWmxRSEJ0TG0xbElEeG9iR0Z5Y21sMlpVQndiUzV0WlQ3Q2p3UVENCkZn b0FJQVVDWUZFMzRRWUxDUWNJQXdJRUZRZ0tBZ1FXQWdFQUFoa0JBaHNEQWg0QkFDRUpFRnZWSk5j dg0KNHZrMEZpRUU2VUtiaDRyMkNEZUg2WUZCVzlVazF5L2krVFFqQ0FEL2EzcENIQUkrbE9qNTR1 TlVTU1NDDQpMMTg2MVBiMjhhazYrYm9Gc3pudUdzQUJBUFVzOHdCcktBdnFnRFZhcVl1V3p3UGNN c2dlYndTSG44RHcNCmp1SDV6VmdPempnRVlGRTFjUklLS3dZQkJBR1hWUUVGQVFFSFFPbDZ3OXNi R1lmZHZOeVVPb3pjcExiZg0KdGluekljK2g1YnEvazFPdU13VUZBd0VJQjhKNEJCZ1dDQUFKQlFK Z1VUZmhBaHNNQUNFSkVGdlZKTmN2DQo0dmswRmlFRTZVS2JoNHIyQ0RlSDZZRkJXOVVrMXkvaStU VGhQQUQ5RlM0WWtwVHRFclY0MU9FMEFpM1gNClIxNlcrT3REa1p3bTZRVTY0VnUzSmJvQkFMMURM QngxRExLRE5kclZhTUZ1NGp4MXBZV0JqTEpVZ0xLeg0Kc2wzM2pETU0NCj01dWlWDQotLS0tLUVO RCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQo= -----------------------040896351af4fb1df2c463dcf5321d3b--

    -----BEGIN PGP SIGNATURE-----
    Version: ProtonMail

    wnUEARYKAAYFAmLLGj4AIQkQW9Uk1y/i+TQWIQTpQpuHivYIN4fpgUFb1STX L+L5NDUtAPsHb6ZZ1yUkh/LmjxPpDEL6UiQWXE3/ugdfc5WhZKM8AgD/YudK wfoMDsKKzVFSd8AzQEXI3XtrPFFNff+mFjD3Twk=
    =JbeG
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From roger.tarani@free.fr@21:1/5 to All on Sun Jul 10 21:00:01 2022
    Sabri KHEMISSA :
    Bonjour,

    Je pense que Proxmox VE [ https://www.proxmox.com/en/proxmox-ve | https://www.proxmox.com/en/proxmox-ve ] adressera une grande partie de tes besoins.
    - Virtualisation multiOS (LXC pour linux et KVM pour une full virtualisation) - L'ensemble des composants est packagé dans une unique plateforme maintenu par la communauté
    - Backups natifs
    - Capacité native de cluster (il faut creuser le sujet du cluster géographique)


    Roger :
    Merci.
    A ma connaissance, proxmox est une solution de HA cluster où il faut au moins deux noeuds reliés avec une faible latence, cad dans le même lieu et pas très éloignés (moins de 10- 20 de câble, de vague mémoire).
    Si je veux atteindre l'objectif d'un cluster distribué géographiquement, (cad : latence > 100 ms ou beaucoup plus), je ne crois pas que proxmox le permette, si ?




    Hugues Larrive :
    Je pense que si, avec DRBD en mode asynchrone...


    Merci. Je regarde ces documents en lien avec DRBD et asynchrone/asynchronous
    [ https://pve.proxmox.com/wiki/DRBD | https://pve.proxmox.com/wiki/DRBD ] -> [ https://docs.linbit.com/docs/users-guide-9.0/#ch-proxmox | https://docs.linbit.com/docs/users-guide-9.0/#ch-proxmox ] on peut lire





    DRBD mirrors data


    *

    in real time . Replication occurs continuously while applications modify the data on the device.
    *

    transparently . Applications need not be aware that the data is stored on multiple hosts.
    *

    synchronously or asynchronously . With synchronous mirroring, applications are notified of write completions after the writes have been carried out on all (connected) hosts. With asynchronous mirroring, applications are notified of write completions when
    the writes have completed locally, which usually is before they have propagated to the other hosts.
    Sérieusement, pour disposer d'une infra fiable de ce type, quel effort ça représente de mettre en oeuvre proxmox VE avec 2 voire 3 noeuds distants en mode asynchrone ?
    Est-ce que ça peut se traiter "en 1 we" ou bien faut-il envisager de consacrer quelques semaines pendant les vacances pour en faire le tour ?

    Est-ce qu'on peut raisonnablement faire un prototype avec deux machines modestes ?

    J'aurais sans doute d'autres questions sur la réplication offerte dans le contexte de logiciels avec des base de données relationnelles (suffit-il d'utiliser l'infra ou faut-il configurer et programmer d'une manière différente de celle pour tourner
    sur un serveur ordinaire ?), mais je vais d'abord lire la doc trouvée qui doit forcémet y répondre.

    Merci
    cordialement

    <html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div data-marker="__QUOTED_TEXT__">
    <div class="protonmail_signature_block protonmail_signature_block-empty" style="font-family:'arial';font-size:14px">
    <div class="protonmail_signature_block-user protonmail_signature_block-empty">

    </div>

    <div class="protonmail_signature_block-proton protonmail_signature_block-empty">

    </div>
    </div>
    <div class="protonmail_quote"><blockquote class="protonmail_quote"><div style="font-family:'arial' , 'helvetica' , sans-serif;font-size:12pt;color:#000000"><div dir="auto">Sabri KHEMISSA : <div><div dir="auto">Bonjour,</div></div><br><div style="padding-
    left:30px" dir="auto"><span style="font-family:'times new roman' , 'new york' , 'times' , serif">Je pense que Proxmox VE <a rel="noreferrer nofollow noopener nofollow noopener noreferrer" href="https://www.proxmox.com/en/proxmox-ve" target="_blank">https:
    //www.proxmox.com/en/proxmox-ve</a> adressera une grande partie de tes besoins.</span></div><div style="padding-left:30px" dir="auto"><span style="font-family:'times new roman' , 'new york' , 'times' , serif">- Virtualisation multiOS (LXC pour linux et
    KVM pour une full virtualisation)</span></div><div style="padding-left:30px" dir="auto"><span style="font-family:'times new roman' , 'new york' , 'times' , serif">- L'ensemble des composants est packagé dans une unique plateforme maintenu par la
    communauté&nbsp;</span></div><div style="padding-left:30px" dir="auto"><span style="font-family:'times new roman' , 'new york' , 'times' , serif">- Backups natifs</span></div><div style="padding-left:30px" dir="auto"><span style="font-family:'times new
    roman' , 'new york' , 'times' , serif">- Capacité native de cluster (il faut creuser le sujet du cluster géographique)</span></div><div style="padding-left:30px" dir="auto"><br></div></div><div><div dir="auto"><div><br data-mce-bogus="1"></div><div>
    Roger : </div><div>Merci.</div><div>A ma connaissance, proxmox est une solution de HA cluster où il faut au moins deux noeuds reliés avec une faible latence, cad dans le même lieu et pas très éloignés (moins de 10- 20 de câble, de vague mémoire).<
    </div><div>Si je veux atteindre l'objectif d'un cluster distribué géographiquement, (cad : latence &gt; 100 ms ou beaucoup plus), je ne crois pas que proxmox le permette, si ?</div></div></div></div></blockquote><div style="font-family:'arial';font-
    size:14px;color:rgb( 34 , 34 , 34 )"><br></div><div style="font-family:'arial';font-size:14px;color:rgb( 34 , 34 , 34 )">Hugues Larrive : </div><div style="font-family:'arial';font-size:14px;color:rgb( 34 , 34 , 34 )">Je pense que si, avec DRBD en mode
    asynchrone...<br></div><div style="font-family:'arial';font-size:14px;color:rgb( 34 , 34 , 34 )"><br data-mce-bogus="1"></div><div style="font-family:'arial';font-size:14px;color:rgb( 34 , 34 , 34 )"><br data-mce-bogus="1"></div><div style="font-family:'
    arial';font-size:14px;color:rgb( 34 , 34 , 34 )"><span style="font-size: 12pt;" data-mce-style="font-size: 12pt;">Merci. Je regarde ces documents en lien avec DRBD et asynchrone/asynchronous</span><br data-mce-bogus="1"></div><div style="font-family:'
    arial';font-size:14px;color:rgb( 34 , 34 , 34 )"><span style="font-size: 12pt;" data-mce-style="font-size: 12pt;"><a href="https://pve.proxmox.com/wiki/DRBD">https://pve.proxmox.com/wiki/DRBD</a>&nbsp;-&gt; <a href="https://docs.linbit.com/docs/users-
    guide-9.0/#ch-proxmox">https://docs.linbit.com/docs/users-guide-9.0/#ch-proxmox</a>on peut lire</span><br data-mce-bogus="1"></div><div style="font-family:'arial';font-size:14px;color:rgb( 34 , 34 , 34 )"><div class="paragraph"><p style="margin: 0px;"
    data-mce-style="margin: 0px;"><br data-mce-bogus="1"></p><p style="margin: 0px;" data-mce-style="margin: 0px;">DRBD mirrors data</p></div><div class="ulist"><ul><li><p style="margin: 0px;" data-mce-style="margin: 0px;"><strong>in real time</strong>.
    Replication occurs continuously while applications modify the data on the device.</p></li><li><p style="margin: 0px;" data-mce-style="margin: 0px;"><strong>transparently</strong>. Applications need not be aware that the data is stored on multiple hosts.</
    </li><li><p style="margin: 0px;" data-mce-style="margin: 0px;"><strong>synchronously</strong> or <strong>asynchronously</strong>. With synchronous mirroring, applications are notified of write completions after the writes have been carried out on all (
    connected) hosts. With asynchronous mirroring, applications are notified of write completions when the writes have completed locally, which usually is before they have propagated to the other hosts.</p></li></ul></div></div><div style="font-family:'arial'
    ;font-size:14px;color:rgb( 34 , 34 , 34 )"><span style="font-size: 12pt;" data-mce-style="font-size: 12pt;">Sérieusement, pour disposer d'une infra fiable de ce type, quel effort ça représente de mettre en oeuvre proxmox VE avec 2 voire 3 noeuds
    distants en mode asynchrone ?</span></div>Est-ce que ça peut se traiter "en 1 we" ou bien faut-il envisager de consacrer quelques semaines pendant les vacances pour en faire le tour ?<br>
    </div><div class="protonmail_quote"><br data-mce-bogus="1"></div><div class="protonmail_quote">Est-ce qu'on peut raisonnablement faire un prototype avec deux machines modestes ?<br data-mce-bogus="1"></div><div class="protonmail_quote"><br data-mce-
    bogus="1"></div><div class="protonmail_quote">J'aurais sans doute d'autres questions sur la réplication offerte dans le contexte de logiciels avec des base de données relationnelles (suffit-il d'utiliser l'infra ou faut-il configurer et programmer d'
    une manière différente de celle pour tourner sur un serveur ordinaire ?), mais je vais d'abord lire la doc trouvée qui doit forcémet y répondre.<br data-mce-bogus="1"></div><div class="protonmail_quote"><br data-mce-bogus="1"></div><div class="
    protonmail_quote">Merci<br data-mce-bogus="1"></div>cordialement<br></div></div></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)