11:40 p.m.
Hi guys,
Got my system (3.2 on CentOS 6.3 - PoC lab v.0.99999) working fairly OK,
with a few issues that's of concern to me.
I've now started using iSCSI storage, but kept running into an issue
where the VM's would go into a paused state.
A bit of digging in the logs show that it's because of a timeout issue
talking to the iSCSI server/target, which for me raises the spectre of
potential corruption, especially under load.
Couldn't understand how this was possible, as I went out & bought some
dedicated hardware to set up a totally separate & isolated "storage"
network, but ended up simply running a cross-over UTP between the
machines (process-of-elimination & all that), but the issue persisted.
This morning I found that one of the mirrored drives started failing, so
(until I've replaced the drive & discovered otherwise) I suspect that
may be the possible cause of the issue.
What occurred to me last night, as this thing was keeping me awake, is
that this might not be the *best* course of action, and started thinking
that maybe another way of doing it, especially since oVirt does some
fairly low-level LVM stuff, is to rather store the VM's on a local
drive, get far better IOPS than I could hope for with iSCSI over GBE,
and rather set up the iSCSI to mirror the local device.
That way the data is still available on the target in the event a
fail-over/migration needs to take place, but that I'm reducing the risks
a bit while improving overall performance.
Is there a way to do this via oVirt, or would I have to do it manually
by setting up storage locally & set up the mirroring via iSCSI manually
as an OS-level?
And if so, what would I be looking for & what sort of caveats would I
have to keep in mind in order to make this setup suitable for use by
multiple hosts in the event a (live-)migration needs to take place? (I'm
pretty new at the iSCSI-thing & LVM knowledge is just passable)
I'd appreciate anyone's insights into this subject
Kind regards
- Jaco
6:49 p.m.
As for the oVirt point of view, oVirt does not support storage mirroring
out of the box unless it used with Gluster FS
As for the iSCSI mirroring, what exactly do you mean by mirroring? If
you refer to replication then you should probably use Gluster for that
matter, if not, can you please send me the actions you are to do
manually to try and achieve this mirroring so I can understand better
On 03/09/2013 11:40 PM, Jaco wrote:
Hi guys,
Got my system (3.2 on CentOS 6.3 - PoC lab v.0.99999) working fairly
OK, with a few issues that's of concern to me.
I've now started using iSCSI storage, but kept running into an issue
where the VM's would go into a paused state.
A bit of digging in the logs show that it's because of a timeout issue
talking to the iSCSI server/target, which for me raises the spectre of
potential corruption, especially under load.
Couldn't understand how this was possible, as I went out & bought some
dedicated hardware to set up a totally separate & isolated "storage"
network, but ended up simply running a cross-over UTP between the
machines (process-of-elimination & all that), but the issue persisted.
This morning I found that one of the mirrored drives started failing,
so (until I've replaced the drive & discovered otherwise) I suspect
that may be the possible cause of the issue.
What occurred to me last night, as this thing was keeping me awake, is
that this might not be the *best* course of action, and started
thinking that maybe another way of doing it, especially since oVirt
does some fairly low-level LVM stuff, is to rather store the VM's on a
local drive, get far better IOPS than I could hope for with iSCSI over
GBE, and rather set up the iSCSI to mirror the local device.
That way the data is still available on the target in the event a
fail-over/migration needs to take place, but that I'm reducing the
risks a bit while improving overall performance.
Is there a way to do this via oVirt, or would I have to do it manually
by setting up storage locally & set up the mirroring via iSCSI
manually as an OS-level?
And if so, what would I be looking for & what sort of caveats would I
have to keep in mind in order to make this setup suitable for use by
multiple hosts in the event a (live-)migration needs to take place?
(I'm pretty new at the iSCSI-thing & LVM knowledge is just passable)
I'd appreciate anyone's insights into this subject
Kind regards
- Jaco
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
8:36 p.m.
Hi Tal,
Thanks for the reply.
The process I was considering following was something like this:
http://koo.fi/blog/2009/06/10/redundant-iscsi-storage-for-linux/
Write my VM images to a local disk & then use an iSCSI target to
maintain a copy in the event that the host goes offline, or if I
otherwise need to do a migration.
I have been looking into GlusterFS (another system I have little
knowledge or experience of), and I believe that it's more of a
network-based highly-available & -resilient system than one designed for
performance. I'm also a little loathe at this late stage of my build to
introduce more subsystems that'll to be planned for, troubleshooted &
maintained - I'm not so sure my existing setup will have good support
for it anyway.
It is certainly something worth-while to consider, but just not at this
stage (probably v.2 of my deployment).
I hope this answers your questions.
Kind regards
- Jaco
On 13/3/14 5:49 , Tal Nisan wrote:
As for the oVirt point of view, oVirt does not support storage
mirroring out of the box unless it used with Gluster FS
As for the iSCSI mirroring, what exactly do you mean by mirroring? If
you refer to replication then you should probably use Gluster for that
matter, if not, can you please send me the actions you are to do
manually to try and achieve this mirroring so I can understand better
On 03/09/2013 11:40 PM, Jaco wrote:
> Hi guys,
>
> Got my system (3.2 on CentOS 6.3 - PoC lab v.0.99999) working fairly
> OK, with a few issues that's of concern to me.
>
> I've now started using iSCSI storage, but kept running into an issue
> where the VM's would go into a paused state.
>
> A bit of digging in the logs show that it's because of a timeout
> issue talking to the iSCSI server/target, which for me raises the
> spectre of potential corruption, especially under load.
> Couldn't understand how this was possible, as I went out & bought
> some dedicated hardware to set up a totally separate & isolated
> "storage" network, but ended up simply running a cross-over UTP
> between the machines (process-of-elimination & all that), but the
> issue persisted.
> This morning I found that one of the mirrored drives started failing,
> so (until I've replaced the drive & discovered otherwise) I suspect
> that may be the possible cause of the issue.
>
> What occurred to me last night, as this thing was keeping me awake,
> is that this might not be the *best* course of action, and started
> thinking that maybe another way of doing it, especially since oVirt
> does some fairly low-level LVM stuff, is to rather store the VM's on
> a local drive, get far better IOPS than I could hope for with iSCSI
> over GBE, and rather set up the iSCSI to mirror the local device.
> That way the data is still available on the target in the event a
> fail-over/migration needs to take place, but that I'm reducing the
> risks a bit while improving overall performance.
>
> Is there a way to do this via oVirt, or would I have to do it
> manually by setting up storage locally & set up the mirroring via
> iSCSI manually as an OS-level?
> And if so, what would I be looking for & what sort of caveats would I
> have to keep in mind in order to make this setup suitable for use by
> multiple hosts in the event a (live-)migration needs to take place?
> (I'm pretty new at the iSCSI-thing & LVM knowledge is just passable)
>
> I'd appreciate anyone's insights into this subject
>
> Kind regards
>
> - Jaco
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
4273
days inactive
4277
days old
2 comments
2 participants
participants (2)
-
Jaco -
Tal Nisan