[Gluster-users] Add single server

Mon May 1 18:00:14 UTC 2017

On Mon, May 1, 2017 at 11:20 PM, Shyam <srangana at redhat.com> wrote:

> On 05/01/2017 01:13 PM, Pranith Kumar Karampuri wrote:
>
>>
>>
>> On Mon, May 1, 2017 at 10:42 PM, Pranith Kumar Karampuri
>> <pkarampu at redhat.com <mailto:pkarampu at redhat.com>> wrote:
>>
>>
>>
>>     On Mon, May 1, 2017 at 10:39 PM, Gandalf Corvotempesta
>>     <gandalf.corvotempesta at gmail.com
>>     <mailto:gandalf.corvotempesta at gmail.com>> wrote:
>>
>>         2017-05-01 18:57 GMT+02:00 Pranith Kumar Karampuri
>>         <pkarampu at redhat.com <mailto:pkarampu at redhat.com>>:
>>
>>         > Yes this is precisely what all the other SDS with metadata
>> servers kind of
>>         > do. They kind of keep a map of on what all servers a particular
>> file/blob is
>>         > stored in a metadata server.
>>
>>         Not exactly. Other SDS has some servers dedicated to metadata and,
>>         personally, I don't like that approach.
>>
>>         > GlusterFS doesn't do that. In GlusterFS what
>>         > bricks need to be replicated is always given and distribute
>> layer on top of
>>         > these replication layer will do the job of distributing and
>> fetching the
>>         > data. Because replication happens at a brick level and not at a
>> file level
>>         > and distribute happens on top of replication and not at file
>> level. There
>>         > isn't too much metadata that needs to be stored per file. Hence
>> no need for
>>         > separate metadata servers.
>>
>>         And this is great, that's why i'm talking about embedding a sort
>>         of database
>>         to be stored on all nodes. no metadata servers, only a mapping
>>         between files
>>         and servers.
>>
>>         > If you know path of the file, you can always know where the
>> file is stored
>>         > using pathinfo:
>>         > Method-2 in the following link:
>>         > https://gluster.readthedocs.io/en/latest/Troubleshooting/gfi
>> d-to-path/
>>         <https://gluster.readthedocs.io/en/latest/Troubleshooting/gf
>> id-to-path/>
>>         >
>>         > You don't need any db.
>>
>>         For the current gluster yes.
>>         I'm talking about a different thing.
>>
>>         In a RAID, you have data stored somewhere on the array, with
>>         metadata
>>         defining how this data should
>>         be wrote or read. obviously, raid metadata must be stored in a
>> fixed
>>         position, or you won't be able to read
>>         that.
>>
>>         Something similiar could be added in gluster (i don't know if it
>>         would
>>         be hard): you store a file mapping in a fixed
>>         position in gluster, then all gluster clients will be able to know
>>         where a file is by looking at this "metadata" stored in
>>         the fixed position.
>>
>>         Like ".gluster" directory. Gluster is using some "internal"
>>         directories for internal operations (".shards", ".gluster",
>>         ".trash")
>>         A ".metadata" with file mapping would be hard to add ?
>>
>>         > Basically what you want, if I understood correctly is:
>>         > If we add a 3rd node with just one disk, the data should
>> automatically
>>         > arrange itself splitting itself to 3 categories(Assuming
>> replica-2)
>>         > 1) Files that are present in Node1, Node2
>>         > 2) Files that are present in Node2, Node3
>>         > 3) Files that are present in Node1, Node3
>>         >
>>         > As you can see we arrived at a contradiction where all the
>> nodes should have
>>         > at least 2 bricks but there is only 1 disk. Hence the
>> contradiction. We
>>         > can't do what you are asking without brick splitting. i.e. we
>> need to split
>>         > the disk into 2 bricks.
>>
>
> Splitting the bricks need not be a post factum decision, we can start with
> larger brick counts, on a given node/disk count, and hence spread these
> bricks to newer nodes/bricks as they are added.
>

Let's say we have 1 disk, we format it with say XFS and that becomes a
brick at the moment. Just curious, what will be the relationship between
brick to disk in this case(If we leave out LVM for this example)?

> If I understand the ceph PG count, it works on a similar notion, till the
> cluster grows beyond the initial PG count (set for the pool) at which point
> there is a lot more data movement (as the pg count has to be increased, and
> hence existing PGs need to be further partitioned) . (just using ceph as an
> example, a similar approach exists for openstack swift with their partition
> power settings).
>
>
>>         I don't think so.
>>         Let's assume a replica 2.
>>
>>         S1B1 + S2B1
>>
>>         1TB each, thus 1TB available (2TB/2)
>>
>>         Adding a third 1TB disks should increase available space to
>>         1.5TB (3TB/2)
>>
>>
>>     I agree it should. Question is how? What will be the resulting
>>     brick-map?
>>
>>
>> I don't see any solution that we can do without at least 2 bricks on
>> each of the 3 servers.
>>
>>
>>
>>
>>     --
>>     Pranith
>>
>>
>>
>>
>> --
>> Pranith
>>
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-users
>>
>>

-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170501/975f9ffc/attachment.html>