Hi Massimiliano, On Thu, Jan 11, 2018 at 6:15 AM, Massimiliano Cuttini <max@xxxxxxxxxxxxx> wrote: > 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. As a technical note, we ran into this need with Storcium, and it is pretty easy to utilize UID indicators using both Areca and LSI/Avago HBAs. You will need the standard control tools available from their web sites, as well as hardware that supports SGPIO (most enterprise JBODs and drives do). There's likely similar options to other HBAs. Areca: UID on: cli64 curctrl=1 set password=<password> cli64 curctrl=<controller #> disk identify drv=<drive ID> UID OFF: cli64 curctrl=1 set password=<password> cli64 curctrl=<controller #> disk identify drv=0 LSI/Avago: UID on: sas2ircu <controller #> locate <enclosure #>:<slot #> ON UID OFF: sas2ircu <controller #> locate <enclosure #>:<slot #> OFF HTH, Alex Gorbachev Storcium > 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 > _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |