Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-users@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <F95EC5DFF06AE04FA54C508ED869D0D2BFC44E@agcex01.CORP.ISWEST.NET>
References: 
 <CAJsq5gDp4eveA1zEPMR9rqo_ENQH0nLNMSvUFXdcFFKXtNUbnA@mail.gmail.com>
	<F95EC5DFF06AE04FA54C508ED869D0D2BFC44E@agcex01.CORP.ISWEST.NET>
Date: Tue, 26 Feb 2013 13:32:38 -0700
Message-ID: 
 <CAJsq5gAKDzdmKv9uWHZ0t_OR4uXU7YH9YU0qHkKcK3htNOc4CQ@mail.gmail.com>
Subject: Re: iSCSI mounts and primary storage
From: Chris Mutchler <chris@leibnizcreations.com>
To: cloudstack-users@incubator.apache.org
Content-Type: multipart/alternative; boundary=e0cb4efe2bd8fa6c1904d6a68e4f

--e0cb4efe2bd8fa6c1904d6a68e4f
Content-Type: text/plain; charset=ISO-8859-1

Clayton,

Thank you for the links and the analysis. It was very helpful and greatly
appreciated.


On Mon, Feb 25, 2013 at 6:18 PM, Clayton Weise <cweise@iswest.net> wrote:

> Chris, I'll start by referencing some additional reading from others
> discussions on this topic:
>
> http://markmail.org/message/d3wg7ll7xzio76qc
>
> http://markmail.org/message/fqj3wmg55qb44ssh
>
> Pretty much anything involving Mike Tutkowski is centered around the topic
> of individual LUNs per VM since it's one of the very cool and unique
> features of SolidFire (per-volume QoS).  Edison has been re-working much of
> the underlying storage architecture within CS to allow for this type of
> configuration.
>
> Next regarding Gluster as primary storage, in my experience with it this
> hasn't ever turned out very good.  Performance usually suffers and KVM and
> CloudStack don't seem to do too well with it but my experience is a little
> over 6 months old at this point and I'm sure things have changed since then
> so I'd welcome anybody else to chime in.  Personally I think you might be
> better served to look at what Wido is doing with Ceph/RBD and CS as it
> seems a more promising scale-out system, but that's just my personal
> opinion based on what I have observed from others and not from my own
> testing.
>
> Finally, as for what others are doing.  For us, we are using iSCSI but we
> share a LUN with multiple customers.  So a given LUN might have many
> smaller volumes on it belonging to a diverse number of accounts.  This is
> due to some technical limitations (256 LUNs per VM host), as well as the
> logistical ones of managing the LUN sprawl which can get messy.  In that
> vein NFS is a very popular alternative.  For various reasons (most of them
> unfounded in my opinion) there seems to be a bias against NFS saying that
> performance suffers.  NFS performs extremely well under most circumstances
> and is much easier to manage since it's just files on a filesystem.  I
> spend quite a bit of time in IRC and I can say from my time in there that
> NFS is generally the most popular choice, and primarily for this reason.
>
> -Clayton
>
> -----Original Message-----
> From: Chris Mutchler [mailto:chris@leibnizcreations.com]
> Sent: Monday, February 25, 2013 10:12 AM
> To: cloudstack-users@incubator.apache.org
> Subject: iSCSI mounts and primary storage
>
> I am in the designing phase of creating a private cloud using CloudStack.
> The current portion I am focusing my efforts on is the primary storage
> design. I could use an iSCSI SAN as the primary storage, but if I do so is
> it possible for CloudStack to create/use individual LUN for each VM as
> opposed to a single LUN for the cluster?
>
> The other primary storage solution I am looking at is using GlusterFS. It
> appears to be another good solution for creating a private cloud with
> expandability and high-availability functionality in mind.
>
> What have other users decided for their primary storage devices and what
> suggestions do you have for someone designing a private cloud solution?
>
> Thank you in advance for you time.
> --
> Chris Mutchler
> chris@leibnizcreations.com
>


-- 
Chris Mutchler
chris@leibnizcreations.com

--e0cb4efe2bd8fa6c1904d6a68e4f--