What you are trying to do will work, because you will not need any kernel related code for object storage, so a one node setup will work for you. -- Sent from my mobile device On 19.08.2013, at 20:29, "Schmitt, Christian" <c.schmitt@xxxxxxxxxxxxxx> wrote: > That sounds bad for me. > As said one of the things we consider is a one node setup, for production. > Not every Customer will afford hardware worth more than ~4000 Euro. > Small business users don't need need the biggest hardware, but i don't > think it's a good way to have a version who uses the filesystem and > one version who use ceph. > > We prefer a Object Storage for our Files. It should work like the > Object Storage of the App Engine. > That scales from 1 to X Servers. > > > 2013/8/19 John Wilkins <john.wilkins@xxxxxxxxxxx>: >> Actually, I wrote the Quick Start guides so that you could do exactly >> what you are trying to do, but mostly from a "kick the tires" >> perspective so that people can learn to use Ceph without imposing >> $100k worth of hardware as a requirement. See >> http://ceph.com/docs/master/start/quick-ceph-deploy/ >> >> I even added a section so that you could do it on one disk--e.g., on >> your laptop. http://ceph.com/docs/master/start/quick-ceph-deploy/#multiple-osds-on-the-os-disk-demo-only >> >> It says "demo only," because you won't get great performance out of a >> single node. Monitors, OSDs, and Journals writing to disk and fsync >> issues would make performance sub-optimal. >> >> For better performance, you should consider a separate drive for each >> Ceph OSD Daemon if you can, and potentially a separate SSD drive >> partitioned for journals. If you can separate the OS and monitor >> drives from the OSD drives, that's better too. >> >> I wrote it as a two-node quick start, because you cannot kernel mount >> the Ceph Filesystem or Ceph Block Devices on the same host as the Ceph >> Storage Cluster. It's a kernel issue, not a Ceph issue. However, you >> can get around this too. If your machine has enough RAM and CPU, you >> can also install virtual machines and kernel mount cephfs and block >> devices in the virtual machines with no kernel issues. You don't need >> to use VMs at all for librbd. So you can install QEMU/KVM, libvirt and >> OpenStack all on the same host too. It's just not an ideal situation >> from performance or high availability perspective. >> >> >> >> On Mon, Aug 19, 2013 at 3:12 AM, Schmitt, Christian >> <c.schmitt@xxxxxxxxxxxxxx> wrote: >>> 2013/8/19 Wolfgang Hennerbichler <wolfgang.hennerbichler@xxxxxxxxxxxxxxxx>: >>>> On 08/19/2013 12:01 PM, Schmitt, Christian wrote: >>>>>> yes. depends on 'everything', but it's possible (though not recommended) >>>>>> to run mon, mds, and osd's on the same host, and even do virtualisation. >>>>> >>>>> Currently we don't want to virtualise on this machine since the >>>>> machine is really small, as said we focus on small to midsize >>>>> businesses. Most of the time they even need a tower server due to the >>>>> lack of a correct rack. ;/ >>>> >>>> whoa :) >>> >>> Yep that's awful. >>> >>>>>>> Our Application, Ceph's object storage and a database? >>>>>> >>>>>> what is 'a database'? >>>>> >>>>> We run Postgresql or MariaDB (without/with Galera depending on the cluster size) >>>> >>>> You wouldn't want to put the data of postgres or mariadb on cephfs. I >>>> would run the native versions directly on the servers and use >>>> mysql-multi-master circular replication. I don't know about similar >>>> features of postgres. >>> >>> No i don't want to put a MariaDB Cluster on CephFS we want to put PDFs >>> in CephFS or Ceph's Object Storage and hold a key or path in the >>> database, also other things like user management will belong to the >>> database >>> >>>>>> shared nothing is possible with ceph, but in the end this really depends >>>>>> on your application. >>>>> >>>>> hm, when disk fails we already doing some backup on a dell powervault >>>>> rd1000, so i don't think thats a problem and also we would run ceph on >>>>> a Dell PERC Raid Controller with RAID1 enabled on the data disk. >>>> >>>> this is open to discussion, and really depends on your use case. >>> >>> Yeah we definitely know that it isn't good to use Ceph on a single >>> node, but i think it's easier to design the application that it will >>> depends on ceph. it wouldn't be easy to manage to have a single node >>> without ceph and more than 1 node with ceph. >>> >>>>>>> Currently we make an archiving software for small customers and we want >>>>>>> to move things on the file system on a object storage. >>>>>> >>>>>> you mean from the filesystem to an object storage? >>>>> >>>>> yes, currently everything is on the filesystem and this is really >>>>> horrible, thousands of pdfs just on the filesystem. we can't scale up >>>>> that easily with this setup. >>>> >>>> Got it. >>>> >>>>> Currently we run on Microsoft Servers, but we plan to rewrite our >>>>> whole codebase with scaling in mind, from 1 to X Servers. So 1, 3, 5, >>>>> 7, 9, ... X²-1 should be possible. >>>> >>>> cool. >>>> >>>>>>> Currently we only >>>>>>> have customers that needs 1 machine or 3 machines. But everything should >>>>>>> work as fine on more. >>>>>> >>>>>> it would with ceph. probably :) >>>>> >>>>> That's nice to hear. I was really scared that we don't find a solution >>>>> that can run on 1 system and scale up to even more. We first looked at >>>>> HDFS but this isn't lightweight. >>>> >>>> not only that, HDFS also has a single point of failure. >>>> >>>>> And the overhead of Metadata etc. >>>>> just isn't that cool. >>>> >>>> :) >>> >>> Yeah that's why I came to Ceph. I think that's probably the way we want to go. >>> Really thank you for your help. It's good to know that I have a >>> solution for the things that are badly designed on our current >>> solution. >>> >>>> _______________________________________________ >>>> 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 >> >> >> >> -- >> John Wilkins >> Senior Technical Writer >> Intank >> john.wilkins@xxxxxxxxxxx >> (415) 425-9599 >> http://inktank.com _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |