4 comentarios sobre “Acerca de:”

1. Dear.
   Many thanks for your awesome site
   I am interested in odoo
   And I followed your steps at
   Odoo&oq 12 pacemaker ha services
   And drbd
   I noted that there is missing articles I can’t found in the site
   For Instance the series started with
   No 1
   2
   3
   4
   5 and 6 and 8 are missing
   And at the end I see
   90
   Which is talking about previous articles where I can’t found in the site
   Plz if it possible guide me to the complete series to understand
   Many thanks

   Responder

   1. Hi,

      I currently no longer use DRBD. Now I use GlusterFS. The complete sequence is the one corresponding to version 3.2. I use 9x, for addenda, or general aspects.

      Thanks for your interest,
      cba

      Responder

      1. thanks a lot
         i follow your guide
         and i am using ubuntu20
         when i install postgresql
         and stop its service to be controlled via the pacmaker
         i faced that error
         Error: /srv/repVol-01/pgsql/data is not accessible or does not exist

         its looks that the cluster is starting the postgresql service befoure gluster-fuse mountig service
         so postgresql is not run
         so to make it run . when i make resource clear or restart postgresql manulaly after the mounting process happen
         But this against the idea of auotmation that cluster can provide
         if i miss some thing please guide me
         best regards

         Responder

         1. Hello,
            I don’t really know your name. But my name is ‘Carlos’.
            You are absolutely right in what you say. Perhaps I have not made clear the main aspect of the subject.
            In any FS replication system, there must be an arbitration, and / or a quorum.
            In this simulation exercise, pacemaker does his job, but it is not enough. A minimum quorum is half plus one, and that with respect to pacemaker and also analyzing the even or odd servers. The two-node only formula works in a limited way. That is used for very poor resources. Not for lockd (I don’t use it anymore). DRBD (I don’t use it anymore, due to its high cost) or glusterd.
            If you get lost, your data will conflict and it will be difficult to recover them. A safe split-brain. And there are several types, … Better to avoid them! FUSE was an impossible paradox a short time ago. Everything should happen and be managed by the kernel. It is a different and new user space. And it works now at last! (versus> kernel 5.8.x Linus Torvalds).
            The main solution is to use a minimum of three servers from a GlusterFS point of view. The third can be an arbitrator of metadata and file names. In production, I would use real data servers, never a third party for metadata (referee). The cost is really irrelevant.
            The postgresql issue is different in a cluster. If there is not enough quorum, glusterd will break your BB. by DD. But you can use PAF. In the latter case, it would be necessary to change the configuration of the bricks in glusterFS so that postgresql could identify the read marks per server. But then the bricks should be identified in a different way and by each server and I reiterate, and to maintain a GFID consistency. This way it will work for sure.
            However, I have preferred to use a lower level and based on low-level attributes so that GlusterFS itself avoids splits-brains.
            I haven’t used Debian / Ubuntu for a long time. I prefer a configuration destined for the ad-hoc configuration file. And the SELinux environment is important too!
            CentOS / RedHat meets those expectations (Ubuntu / Debian too, but I use another system). Debian / Ubuntu helper tools make you lose perspective.
            Very good your questions!
            Nice to help you, or to help me!

            Best regards,

            carlos

            Responder

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.