4:29 a.m.
This is a multi-part message in MIME format.
--------------A485472F7B236F6466AB7AEC
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Hello,
[Unusual setup]
Last week, I eventually managed to make a 4.2.1.7 oVirt work with
iscsi-multipathing on both hosts and guest, connected to a Dell
Equallogic SAN which is providing one single virtual ip - my hosts have
two dedicated NICS for iscsi, but on the same VLAN. Torture-tests showed
good resilience.
[Classical setup]
But this year, we plan to create at least two additional DCs but to
connect their hosts to a "classical" SAN, ie which provides TWO IPs on
segregated VLANs (not routed), and we'd like to use the same
iscsi-multipathing feature.
The discussion below could lead to think that oVirt needs the two iscsi
VLANs to be routed, allowing the hosts in one VLAN to access to
resources in the other.
As Vinicius explained, this is not a best practice to say the least.
Searching through the mailing list archive, I found no answer to
Vinicius' question.
May a Redhat storage and/or network expert enlighten us on these points?
Regards,
--
Nicolas Ecarnot
Le 21/07/2017 à 20:56, Vinícius Ferrão a écrit :
> On 21 Jul 2017, at 15:12, Yaniv Kaul <ykaul(a)redhat.com
> <mailto:ykaul@redhat.com>> wrote:
>
>
>
> On Wed, Jul 19, 2017 at 9:13 PM, Vinícius Ferrão <ferrao(a)if.ufrj.br
> <mailto:ferrao@if.ufrj.br>> wrote:
>
> Hello,
>
> I’ve skipped this message entirely yesterday. So this is per
> design? Because the best practices of iSCSI MPIO, as far as I
> know, recommends two completely separate paths. If this can’t be
> achieved with oVirt what’s the point of running MPIO?
>
>
> With regular storage it is quite easy to achieve using 'iSCSI bonding'.
> I think the Dell storage is a bit different and requires some more
> investigation - or experience with it.
> Y.
Yaniv, thank you for answering this. I’m really hoping that a solution
would be found.
Actually I’m not running anything from DELL. My storage system is
FreeNAS which is pretty standard and, as far as I know, iSCSI
practices dictates segregate networks for proper working.
All other major virtualization products supports iSCSI this way:
vSphere, XenServer and Hyper-V. So I was really surprised that oVirt
(and even RHV, I requested a trial yesterday) does not implement ISCSI
with the well know best practices.
There’s a picture of the architecture that I take from Google when
searching for ”mpio best practives”:
https://image.slidesharecdn.com/2010-12-06-midwest-reg-vmug-101206110506-...
Ans as you can see it’s segregated networks on a machine reaching the
same target.
In my case, my datacenter has five Hypervisor Machines, with two NICs
dedicated for iSCSI. Both NICs connect to different converged ethernet
switches and the iStorage is connected the same way.
So it really does not make sense that a the first NIC can reach the
second NIC target. In a case of a switch failure the cluster will go
down anyway, so what’s the point of running MPIO? Right?
Thanks once again,
V.
--------------A485472F7B236F6466AB7AEC
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hello,<br>
<br>
[<font color="#ff0000">Unusual setup</font>]<br>
Last week, I eventually managed to make a 4.2.1.7 oVirt work with
iscsi-multipathing on both hosts and guest, connected to a Dell
Equallogic SAN which is providing one single virtual ip - my hosts
have two dedicated NICS for iscsi, but <font color="#ff0000">on
the same VLAN</font>. Torture-tests showed good resilience.<br>
<br>
[<font color="#009900">Classical setup</font>]<br>
But this year, we plan to create at least two additional DCs but
to connect their hosts to a "classical" SAN, ie which provides TWO
IPs <font color="#009900">on segregated VLANs (not
routed)</font>,
and we'd like to use the same iscsi-multipathing feature.<br>
<br>
The discussion below could lead to think that oVirt needs the two
iscsi VLANs to be routed, allowing the hosts in one VLAN to access
to resources in the other.<br>
As Vinicius explained, this is not a best practice to say the
least.<br>
<br>
Searching through the mailing list archive, I found no answer to
Vinicius' question.<br>
<br>
May a Redhat storage and/or network expert enlighten us on these
points?<br>
<br>
Regards,<br>
<br>
-- <br>
Nicolas Ecarnot<br>
<br>
Le 21/07/2017 à 20:56, Vinícius Ferrão a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:54FF808B-215E-441D-9864-38DBDD9F32E8@if.ufrj.br">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<div class=""><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">On 21 Jul 2017, at 15:12, Yaniv Kaul
<<a
href="mailto:ykaul@redhat.com" class=""
moz-do-not-send="true">ykaul(a)redhat.com</a>&gt;
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class=""><br
class="">
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Wed, Jul 19, 2017 at 9:13
PM, Vinícius Ferrão <span dir="ltr" class="">
<<a href="mailto:ferrao@if.ufrj.br"
target="_blank" class=""
moz-do-not-send="true">ferrao(a)if.ufrj.br</a>&gt;</span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br class="">
<br class="">
I’ve skipped this message entirely yesterday. So
this is per design? Because the best practices of
iSCSI MPIO, as far as I know, recommends two
completely separate paths. If this can’t be achieved
with oVirt what’s the point of running MPIO?<br
class="">
</blockquote>
<div class=""><br class="">
</div>
<div class="">With regular storage it is quite easy to
achieve using 'iSCSI bonding'.</div>
<div class="">I think the Dell storage is a bit
different and requires some more investigation - or
experience with it.</div>
<div class=""> Y.</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Yaniv, thank you for answering this. I’m really hoping that
a solution would be found.</div>
<div><br class="">
</div>
<div>Actually I’m not running anything from DELL. My storage
system is FreeNAS which is pretty standard and, as far as I
know, iSCSI practices dictates segregate networks for proper
working.</div>
<div><br class="">
</div>
<div>All other major virtualization products supports iSCSI this
way: vSphere, XenServer and Hyper-V. So I was really surprised
that oVirt (and even RHV, I requested a trial yesterday) does
not implement ISCSI with the well know best practices.</div>
<div><br class="">
</div>
<div>There’s a picture of the architecture that I take from
Google when searching for ”mpio best practives”:
<a
href="https://image.slidesharecdn.com/2010-12-06-midwest-reg-vmug-10...
class="" moz-do-not-send="true">
https://image.slidesharecdn.com/2010-12-06-midwest-reg-vmug-101206110506-...
<div><br class="">
</div>
<div>Ans as you can see it’s segregated networks on a machine
reaching the same target.</div>
<div><br class="">
</div>
<div>In my case, my datacenter has five Hypervisor Machines,
with two NICs dedicated for iSCSI. Both NICs connect to
different converged ethernet switches and the iStorage is
connected the same way.</div>
<div><br class="">
</div>
<div>So it really does not make sense that a the first NIC can
reach the second NIC target. In a case of a switch failure the
cluster will go down anyway, so what’s the point of running
MPIO? Right?</div>
<div><br class="">
</div>
<div>Thanks once again,</div>
<div>V.</div>
</div>
</blockquote>
</body>
</html>
--------------A485472F7B236F6466AB7AEC--
![href="https://image.slidesharecdn.com/2010-12-06-midwest-reg-vmug-10...](http://href="https://image.slidesharecdn.com/2010-12-06-midwest-reg-vmug-101206110506-phpapp01/95/nextgeneration-best-practices-for-vmware-and-storage-15-728.jpg?cb=1296301640%22){kind=link}
