|
Hi everybody,
i'm always looking at CEPH for the future.
But I do see several issue that are leaved unresolved and block
nearly future adoption.
I would like to know if there are some answear already:
1) Separation between Client and Server distribution.
At this time you have always to update client & server in
order to match the same distribution of Ceph.
This is ok in the early releases but in future I do expect that
the ceph-client is ONE, not many for every major version.
The client should be able to self determinate what version of the
protocol and what feature are enabable and connect to at least 3
or 5 older major version of Ceph by itself.
2) Kernel is old -> feature mismatch
Ok, kernel is old, and so? Just do not use it and turn to NBD.
And please don't let me even know, just virtualize under the hood.
3) Management complexity
Ceph is amazing, but is just too big to have everything under
control (too many services).
Now there is a management console, but as far as I read this
management console just show basic data about performance.
So it doesn't manage at all... it's just a monitor...
In the end You have just to manage everything by your
command-line.
In order to manage by web it's mandatory:
- create, delete, enable, disable services
If I need to run ISCSI redundant gateway, do I really need to
cut&paste command from your online docs?
Of course no. You just can script it better than what every
admin can do.
Just give few arguments on the html forms and that's all.
- create, delete, enable, disable users
I have to create users and keys for 24 servers. Do you really
think it's possible to make it without some bad transcription or
bad cut&paste of the keys across all servers.
Everybody end by just copy the admin keys across all servers,
giving very unsecure full permission to all clients.
- create MAPS (server, datacenter, rack, node, osd).
This is mandatory to design how the data need to be replicate.
It's not good create this by script or shell, it's needed a
graph editor which can dive you the perpective of what will be
copied where.
- check hardware below the hood
It's missing the checking of the health of the hardware below.
But Ceph was born as a storage software that ensure redundacy
and protect you from single failure.
So WHY did just ignore to check the healths of disks with SMART?
FreeNAS just do a better work on this giving lot of tools to
understand which disks is which and if it will fail in the
nearly future.
Of course also Ceph could really forecast issues by itself and
need to start to integrate with basic hardware IO.
For example, should be possible to enable disable UID on the
disks in order to know which one need to be replace.
I guess this kind of feature are quite standard across all linux
distributions.
The management complexity can be completly overcome with a great
Web Manager.
A Web Manager, in the end is just a wrapper for Shell Command from
the CephAdminNode to others.
If you think about it a wrapper is just tons of time easier to
develop than what has been already developed.
I do really see that CEPH is the future of storage. But there is
some quick-avoidable complexity that need to be reduced.
If there are already some plan for these issue I really would
like to know.
Thanks,
Max
|
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
