<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 12, 2017 at 6:01 PM, Nicolas Ecarnot <span dir="ltr">&lt;<a href="mailto:nicolas@ecarnot.net" target="_blank">nicolas@ecarnot.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <div class="gmail-m_-7918606571867829382moz-cite-prefix">Hi,<br>
      <br>
      As we are using a very similar hardware and usage as Mark (Dell
      poweredge hosts, Dell Equallogic SAN, iSCSI, and tons of LUNs for
      all those VMs), I&#39;m jumping into this thread.<span class="gmail-"><br>
      <br>
      Le 12/01/2017 à 16:29, Yaniv Kaul a écrit :<br>
    </span></div><span class="gmail-">
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><br>
            <div>While it&#39;s a bit of a religious war on what is
              preferred with iSCSI - network level bonding (LACP) or
              multipathing on the iSCSI level, I&#39;m on the multipathing
              side. The main reason is that you may end up easily using
              just one of the paths in a bond - if your policy is not
              set correct on how to distribute connections between the
              physical links (remember that each connection sticks to a
              single physical link. So it really depends on the hash
              policy and even then - not so sure). With iSCSI
              multipathing you have more control - and it can also be
              determined by queue depth, etc.</div>
            <div>(In your example, if you have SRC A -&gt; DST 1 and SRC
              B -&gt; DST 1 (as you seem to have), both connections may
              end up on the same physical NIC.)</div>
            <div><br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
              <div lang="EN-GB">
                <div class="gmail-m_-7918606571867829382m_7631641247395573674WordSection1">
                  <p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"></span></p>
                  <p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif"> </span></p>
                  <p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif">If
                      we reduce the number of storage domains, we reduce
                      the number of devices and therefore the number of
                      LVM Physical volumes that appear in Linux correct?
                      At the moment each connection results in a Linux
                      device which has its own queue. We have some
                      guests with high IO loads on their device whilst
                      others are low. All the storage domain / datastore
                      sizing guides we found seem to imply it’s a
                      trade-off between ease of management (i.e not
                      having millions of domains to manage), IO
                      contention between guests on a single large
                      storage domain / datastore and possible wasted
                      space on storage domains. If you have further
                      information on recommendations, I am more than
                      willing to change things as this problem is making
                      our environment somewhat unusable at the moment. I
                      have hosts that I can’t bring online and therefore
                      reduced resiliency in clusters. They used to work
                      just fine but the environment has grown over the
                      last year and we also upgraded the Ovirt version
                      from 3.6 to 4.x. We certainly had other problems,
                      but host activation wasn’t one of them and it’s a
                      problem that’s driving me mad.</span></p>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I would say that each path has its own device (and
              therefore its own queue). So I&#39;d argue that you may want
              to have (for example) 4 paths to each LUN or perhaps more
              (8?). For example, with 2 NICs, each connecting to two
              controllers, each controller having 2 NICs (so no SPOF and
              nice number of paths).</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Here, one key point I&#39;m trying (to no avail) to discuss for years
    with Redhat people, and either I did not understood, either I wasn&#39;t
    clear enough, or Redhat people answered me they owned no Equallogic
    SAN to test it, is :<br>
    My (and maybe many others) Equallogic SAN has two controllers, but
    is publishing only *ONE* virtual ip address.<br></div></blockquote><div><br></div><div>You are completely right - you keep saying that and I keep forgetting that. I apologize. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    On one of our other EMC SAN, publishing *TWO* ip addresses, which
    can be published in two different subnets, I fully understand the
    benefits and working of multipathing (and even in the same subnet,
    our oVirt setup is happily using multipath).<br>
    <br>
    But on one of our oVirt setup using the Equallogic SAN, we have no
    choice but point our hosts iSCSI interfaces to one single SAN ip, so
    no multipath here.<br>
    <br>
    At this point, we saw no other mean than using bonding mode 1 to
    reach our SAN, which is terrible for storage experts.<br></div></blockquote><div><br></div><div>You could, if you do it properly, have an active-active mode, no?. And if the hash policy is correct (for example, layer3+4) you might get both slaves useful. Also, multiple sessions can be achieved with iscsi.conf&#39;s session.nr_sessions (though I&#39;m not sure we don&#39;t have a bug where we don&#39;t disconnect all sessions?).</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <br>
    <br>
    To come back to Mark&#39;s story, we are still using 3.6.5 DCs and
    planning to upgrade.<br>
    Reading all this is making me delay this step.</div></blockquote><div><br></div><div>Well, it&#39;d be nice to get to the bottom of it, but I&#39;m quite sure it has relatively nothing to do with 4.0.</div><div>Y.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-HOEnZb"><font color="#888888"><br>
    <br>
    -- <br>
    Nicolas ECARNOT<br>
  </font></span></div>

<br>______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@ovirt.org">Users@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/users</a><br>
<br></blockquote></div><br></div></div>