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@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
