From: John Wilkins Date: Mon, 6 May 2013 16:43:41 +0000 (-0700) Subject: doc: Forwarding link. FAQ migrated to new Ceph wiki. X-Git-Tag: v0.62~32 X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=41eecf4f81e4ea2ac324c5f16766a22333cfbf1b;p=ceph.git doc: Forwarding link. FAQ migrated to new Ceph wiki. Signed-off-by: John Wilkins --- diff --git a/doc/faq.rst b/doc/faq.rst index cec5808d7e86..0ee320544108 100644 --- a/doc/faq.rst +++ b/doc/faq.rst @@ -2,382 +2,10 @@ Frequently Asked Questions ============================ -These questions have been frequently asked on the ceph-users and ceph-devel -mailing lists, the IRC channel, and on the `Ceph.com`_ blog. +We provide answers to frequently asked questions from the ``ceph-users`` and +``ceph-devel`` mailing lists, the IRC channel, and on the `Ceph.com`_ blog. +Ceph FAQs now reside at the `Ceph Wiki`_. .. _Ceph.com: http://ceph.com +.. _Ceph Wiki: http://wiki.ceph.com/03FAQs - -Is Ceph Production-Quality? -=========================== - -Ceph's object store (RADOS) is production ready. Large-scale storage systems (i.e., -petabytes of data) use Ceph's RESTful Object Gateway (RGW), which provides APIs -compatible with Amazon's S3 and OpenStack's Swift. Many deployments also use -the Ceph Block Device (RBD), including deployments of OpenStack and CloudStack. -`Inktank`_ provides commercial support for the Ceph object store, Object -Gateway, block devices and CephFS with running a single metadata server. - -The CephFS POSIX-compliant filesystem is functionally complete and has been -evaluated by a large community of users. There are production systems using -CephFS with a single metadata server. The Ceph community is actively testing -clusters with multiple metadata servers for quality assurance. Once CephFS -passes QA muster when running with multiple metadata servers, `Inktank`_ will -provide commercial support for CephFS with multiple metadata servers, too. - -.. _Inktank: http://inktank.com - - -What Kind of Hardware Does Ceph Require? -======================================== - -Ceph runs on commodity hardware. A typical configuration involves a -rack mountable server with a baseboard management controller, multiple -processors, multiple drives, and multiple NICs. There are no requirements for -proprietary hardware. For details, see `Ceph Hardware Recommendations`_. - - -What Kind of OS Does Ceph Require? -================================== - -Ceph runs on Linux for both the client and server side. - -Ceph runs on Debian/Ubuntu distributions, which you can install from `APT -packages`_. - -Ceph also runs on Fedora and Enterprise Linux derivates (RHEL, CentOS) using -`RPM packages`_ . - -You can also download Ceph source `tarballs`_ and build Ceph for your -distribution. See `Installation`_ for details. - -.. _try-ceph: - -How Can I Give Ceph a Try? -========================== - -Follow our `Quick Start`_ guides. They will get you up an running quickly -without requiring deeper knowledge of Ceph. Our `Quick Start`_ guides will also -help you avoid a few issues related to limited deployments. If you choose to -stray from the Quick Starts, there are a few things you need to know. - -We recommend using at least two hosts, and a recent Linux kernel. In older -kernels, Ceph can deadlock if you try to mount CephFS or RBD client services on -the same host that runs your test Ceph cluster. This is not a Ceph-related -issue. It's related to memory pressure and needing to relieve free memory. -Recent kernels with up-to-date ``glibc`` and ``syncfs(2)`` reduce this issue -considerably. However, a memory pool large enough to handle incoming requests is -the only thing that guarantees against the deadlock occuring. When you run Ceph -clients on a Ceph cluster machine, loopback NFS can experience a similar problem -related to buffer cache management in the kernel. You can avoid these scenarios -entirely by using a separate client host, which is more realistic for deployment -scenarios anyway. - -We recommend using at least two OSDs with at least two replicas of the data. -OSDs report other OSDs to the monitor, and also interact with other OSDs when -replicating data. If you have only one OSD, a second OSD cannot check its -heartbeat. Also, if an OSD expects another OSD to tell it which placement groups -it should have, the lack of another OSD prevents this from occurring. So a -placement group can remain stuck "stale" forever. These are not likely -production issues. - -Finally, `Quick Start`_ guides are a way to get you up and running quickly. To -build performant systems, you'll need a drive for each OSD, and you will likely -benefit by writing the OSD journal to a separate drive from the OSD data. - - -How Many OSDs Can I Run per Host? -================================= - -Theoretically, a host can run as many OSDs as the hardware can support. Many -vendors market storage hosts that have large numbers of drives (e.g., 36 drives) -capable of supporting many OSDs. We don't recommend a huge number of OSDs per -host though. Ceph was designed to distribute the load across what we call -"failure domains." See `CRUSH Maps`_ for details. - -At the petabyte scale, hardware failure is an expectation, not a freak -occurrence. Failure domains include datacenters, rooms, rows, racks, and network -switches. In a single host, power supplies, motherboards, NICs, and drives are -all potential points of failure. - -If you place a large percentage of your OSDs on a single host and that host -fails, a large percentage of your OSDs will fail too. Having too large a -percentage of a cluster's OSDs on a single host can cause disruptive data -migration and long recovery times during host failures. We encourage -diversifying the risk across failure domains, and that includes making -reasonable tradeoffs regarding the number of OSDs per host. - - -Can I Use the Same Drive for Multiple OSDs? -=========================================== - -Yes. **Please don't do this!** Except for initial evaluations of Ceph, we do not -recommend running multiple OSDs on the same drive. In fact, we recommend -**exactly** the opposite. Only run one OSD per drive. For better performance, -run journals on a separate drive from the OSD drive, and consider using SSDs for -journals. Run operating systems on a separate drive from any drive storing data -for Ceph. - -Storage drives are a performance bottleneck. Total throughput is an important -consideration. Sequential reads and writes are important considerations too. -When you run multiple OSDs per drive, you split up the total throughput between -competing OSDs, which can slow performance considerably. - - -Why Do You Recommend One Drive Per OSD? -======================================= - -Ceph OSD performance is one of the most common requests for assistance, and -running an OS, a journal and an OSD on the same disk is a frequently the -impediment to high performance. Total throughput and simultaneous reads and -writes are a major bottleneck. If you journal data, run an OS, or run multiple -OSDs on the same drive, you will very likely see performance degrade -significantly--especially under high loads. - -Running multiple OSDs on a single drive is fine for evaluation purposes. We -even encourage that in our `5-minute quick start`_. However, just because it -works does NOT mean that it will provide acceptable performance in an -operational cluster. - - -What Underlying Filesystem Do You Recommend? -============================================ - -Currently, we recommend using XFS as the underlying filesystem for OSD drives. -We think ``btrfs`` will become the optimal filesystem. However, we still -encounter enough issues that we do not recommend it for production systems yet. -See `Filesystem Recommendations`_ for details. - - -How Does Ceph Ensure Data Integrity Across Replicas? -==================================================== - -Ceph periodically scrubs placement groups to ensure that they contain the same -information. Low-level or deep scrubbing reads the object data in each replica -of the placement group to ensure that the data is identical across replicas. - - -How Many NICs Per Host? -======================= - -You can use one :abbr:`NIC (Network Interface Card)` per machine. We recommend a -minimum of two NICs: one for a public (front-side) network and one for a cluster -(back-side) network. When you write an object from the client to the primary -OSD, that single write only accounts for the bandwidth consumed during one leg -of the transaction. If you store multiple copies (usually 2-3 copies in a -typical cluster), the primary OSD makes a write request to your secondary and -tertiary OSDs. So your back-end network traffic can dwarf your front-end network -traffic on writes very easily. - - -What Kind of Network Throughput Do I Need? -========================================== - -Network throughput requirements depend on your load. We recommend starting with -a minimum of 1GB Ethernet. 10GB Ethernet is more expensive, but often comes with -some additional advantages, including virtual LANs (VLANs). VLANs can -dramatically reduce the cabling requirements when you run front-side, back-side -and other special purpose networks. - -The number of object copies (replicas) you create is an important factor, -because replication becomes a larger network load than the initial write itself -when making multiple copies (e.g., triplicate). Network traffic between Ceph and -a cloud-based system such as OpenStack or CloudStack may also become a factor. -Some deployments even run a separate NIC for management APIs. - -Finally load spikes are a factor too. Certain times of the day, week or month -you may see load spikes. You must plan your network capacity to meet those load -spikes in order for Ceph to perform well. This means that excess capacity may -remain idle or unused during low load times. - - -Can Ceph Support Multiple Data Centers? -======================================= - -Yes, but with safeguards to ensure data safety. When a client writes data to -Ceph the primary OSD will not acknowledge the write to the client until the -secondary OSDs have written the replicas synchronously. See `How Ceph Scales`_ -for details. - -The Ceph community is working to ensure that OSD/monitor heartbeats and peering -processes operate effectively with the additional latency that may occur when -deploying hardware in different geographic locations. See `Monitor/OSD -Interaction`_ for details. - -If your data centers have dedicated bandwidth and low latency, you can -distribute your cluster across data centers easily. If you use a WAN over the -Internet, you may need to configure Ceph to ensure effective peering, heartbeat -acknowledgement and writes to ensure the cluster performs well with additional -WAN latency. - -The Ceph community is working on an asynchronous write capability via the Ceph -Object Gateway (RGW) which will provide an eventually-consistent copy of data -for disaster recovery purposes. This will work with data read and written via -the Object Gateway only. Work is also starting on a similar capability for Ceph -Block devices which are managed via the various cloudstacks. - - -How Does Ceph Authenticate Users? -================================= - -Ceph provides an authentication framework called ``cephx`` that operates in a -manner similar to Kerberos. The principal difference is that Ceph's -authentication system is distributed too, so that it doesn't constitute a single -point of failure. For details, see `Ceph Authentication & Authorization`_. - - -Does Ceph Authentication Provide Multi-tenancy? -=============================================== - -Ceph provides authentication at the `pool`_ level, which may be sufficient -for multi-tenancy in limited cases. Ceph plans on developing authentication -namespaces within pools in future releases, so that Ceph is well-suited for -multi-tenancy within pools. - -Can Ceph use other Multi-tenancy Modules? -========================================= - -The Bobtail release of Ceph integrates the Object Gateway with OpenStack's Keystone. -See `Keystone Integration`_ for details. - -.. _Keystone Integration: ../radosgw/config#integrating-with-openstack-keystone - - -Does Ceph Enforce Quotas? -========================= - -Currently, Ceph doesn't provide enforced storage quotas. The Ceph community has -discussed enforcing user quotas within CephFS. - - -Does Ceph Track Per User Usage? -=============================== - -The CephFS filesystem provides user-based usage tracking on a subtree basis. -RADOS Gateway also provides detailed per-user usage tracking. RBD and the -underlying object store do not track per user statistics. The underlying object -store provides storage capacity utilization statistics. - - -Does Ceph Provide Billing? -========================== - -Usage information is available via a RESTful API for the Ceph Object Gateway -which can be integrated into billing systems. Usage data at the RADOS pool -level is not currently possible but is on the roadmap. - -Can Ceph Export a Filesystem via NFS or Samba/CIFS? -=================================================== - -Ceph doesn't export CephFS via NFS or Samba. However, you can use a gateway to -serve a CephFS filesystem to NFS or Samba clients. - - -Can I Access Ceph via a Hypervisor? -=================================== - -Currently, the `QEMU`_ hypervisor can interact with the Ceph `block device`_. -The :abbr:`KVM (Kernel Virtual Machine)` `module`_ and the `librbd` library -allow you to use QEMU with Ceph. Most Ceph deployments use the `librbd` library. -Cloud solutions like `OpenStack`_ and `CloudStack`_ interact `libvirt`_ and QEMU -to as a means of integrating with Ceph. - -Ceph integrates cloud solutions via ``libvirt`` and QEMU. The Ceph community -is also looking to support the Xen hypervisor in a future release. - -There is interest in support for VMWare, but there is no deep-level integration -between VMWare and Ceph as yet. - - -Can Block, CephFS, and Gateway Clients Share Data? -================================================== - -For the most part, no. You cannot write data to Ceph using RBD and access the -same data via CephFS, for example. You cannot write data with RADOS gateway and -read it with RBD. However, you can write data with the RADOS Gateway -S3-compatible API and read the same data using the RADOS Gateway -Swift-comptatible API. - -RBD, CephFS and the RADOS Gateway each have their own namespace. The way they -store data differs significantly enough that it isn't possible to use the -clients interchangeably. However, you can use all three types of clients, and -clients you develop yourself via ``librados`` simultaneously on the same -cluster. - - -Which Ceph Clients Support Striping? -==================================== - -Ceph clients--RBD, CephFS and RADOS Gateway--providing striping capability. For -details on striping, see `Striping`_. - - -What Programming Languages can Interact with the Object Store? -============================================================== - -Ceph's ``librados`` is written in the C programming language. There are -interfaces for other languages, including: - -- C++ -- Java -- PHP -- Python -- Ruby - - -Can I Develop a Client With Another Language? -============================================= - -Ceph does not have many native bindings for ``librados`` at this time. If you'd -like to fork Ceph and build a wrapper to the C or C++ versions of ``librados``, -please check out the `Ceph repository`_. You can also use other languages that -can use the ``librados`` native bindings (e.g., you can access the C/C++ bindings -from within Perl). - - -Do Ceph Clients Run on Windows? -=============================== - -No. There are no immediate plans to support Windows clients at this time. However, -you may be able to emulate a Linux environment on a Windows host. For example, -Cygwin may make it feasible to use ``librados`` in an emulated environment. - - -How can I add a question to this list? -====================================== - -If you'd like to add a question to this list (hopefully with an -accompanying answer!), you can find it in the doc/ directory of our -main git repository: - - `https://github.com/ceph/ceph/blob/master/doc/faq.rst`_ - - -We use Sphinx to manage our documentation, and this page is generated -from reStructuredText source. See the section on Building Ceph -Documentation for the build procedure. - - - -.. _Ceph Hardware Recommendations: ../install/hardware-recommendations -.. _APT packages: ../install/debian -.. _RPM packages: ../install/rpm -.. _tarballs: ../install/get-tarballs -.. _Installation: ../install -.. _CRUSH Maps: ../rados/operations/crush-map -.. _5-minute quick start: ../start/quick-start -.. _How Ceph Scales: ../architecture#how-ceph-scales -.. _Monitor/OSD Interaction: ../rados/configuration/mon-osd-interaction -.. _Ceph Authentication & Authorization: ../rados/operations/auth-intro -.. _Ceph repository: https://github.com/ceph/ceph -.. _QEMU: ../rbd/qemu-rbd -.. _block device: ../rbd -.. _module: ../rbd/rbd-ko -.. _libvirt: ../rbd/libvirt -.. _OpenStack: ../rbd/rbd-openstack -.. _CloudStack: ../rbd/rbd-cloudstack -.. _pool: ../rados/operations/pools -.. _Striping: ../architecture##how-ceph-clients-stripe-data -.. _https://github.com/ceph/ceph/blob/master/doc/faq.rst: https://github.com/ceph/ceph/blob/master/doc/faq.rst -.. _Filesystem Recommendations: ../rados/configuration/filesystem-recommendations -.. _Quick Start: ../start \ No newline at end of file