======================
======================About this Document======================
-This document describes the features and benefits of using the Ceph Unified Distributed Storage System, and why it is superior to other systems. The audience for this document consists of sales and marketing personnel, new customers, and all persons who need to get a basic overview of the features and functionality of the system.
+This document describes the features and benefits of using the Ceph Unified Distributed Storage System, and why it is superior to other systems.
+The audience for this document consists of sales and marketing personnel, new customers, and all persons who need to get a basic overview of the features and functionality of the system.
======================Introduction to Ceph======================
Ceph is a unified, distributed file system that operates on a large number of hosts connected by a network. Ceph has been designed to accommodate multiple petabytes of storage with ease. Since file sizes and network systems are always increasing, Ceph is perfectly positioned to accommodate these new technologies with its unique, self-healing and self-replicating architecture. Customers that need to move large amounts of metadata, such as media and entertainment companies, can greatly benefit from this product. Ceph is also dynamic; no need to cache data like those old-fashioned client-servers!
Benefits of Using Ceph
-Ceph\92s flexible and scalable architecture translates into cost savings for users. Its powerful load balancing technology ensures the highest performance in terms of both speed and reliability. Nodes can be added \93on the fly\94 with no impact to the system. In the case of node failure, the load is re-distributed with no degradation to the system. Failure detection is rapid and immediately remedied by efficiently re-adding nodes that were temporarily cut off from the network.
+Ceph\92s flexible and scalable architecture translates into cost savings for users. Its powerful load balancing technology ensures the highest performance in terms of both speed and
+reliability. Nodes can be added \93on the fly\94 with no impact to the system. In the case of node failure, the load is re-distributed with no degradation to the system.
+ Failure detection is rapid and immediately remedied by efficiently re-adding nodes that were temporarily cut off from the network.
Manageability
-Ceph is easy to manage, requiring little or no system administrative intervention. Its powerful placement algorithm and intelligent nodes manage data seamlessly across any node configuration. It also features multiple access methods to its object storage, block storage, and file systems. Figure 1 displays this configuration.
-.
-
-The Reliable Autonomic Distributed Object Store (RADOS) provides a scalable object storage management platform. RADOS allows the Object Storage Devices (OSD) to operate autonomously when recovering from failures or migrating data to expand clusters. RADOS employs existing node device intelligence to maximized scalability.
-The RADOS Block Device (RBD) provides a block device interface to a Linux machine, while striping the data across multiple RADOS objects for improved performance. RDB is supported for Linux kernels 2.6.37 and higher. Each RDB device contains a directory with files and information
+Ceph is easy to manage, requiring little or no system administrative intervention. Its powerful placement algorithm and intelligent nodes manage data seamlessly across any node
+configuration. It also features multiple access methods to its object storage, block storage, and file systems. Figure 1 displays this configuration.
+<img> CephConfig.jpg.
+======================RADOS======================
+The Reliable Autonomic Distributed Object Store (RADOS) provides a scalable object storage management platform. RADOS allows the Object Storage Devices (OSD) to operate autonomously
+when recovering from failures or migrating data to expand clusters. RADOS employs existing node device intelligence to maximized scalability.
+The RADOS Block Device (RBD) provides a block device interface to a Linux machine, while striping the data across multiple RADOS objects for improved performance.
+RDB is supported for Linux kernels 2.6.37 and higher. Each RDB device contains a directory with files and information
======================RADOS GATEWAY======================
``radosgw`` is an S3-compatible RESTful HTTP service for object
storage, using RADOS storage.
-The RADOS Block Device (RBD) provides a block device interface to a Linux machine. To the user, RDB is transparent, which means that the entire Ceph system looks like a single, limitless hard drive that is always up and has no size limitations. .
+The RADOS Block Device (RBD) provides a block device interface to a Linux machine. To the user, RDB is transparent, which means that the entire Ceph system looks like a single,
+limitless hard drive that is always up and has no size limitations. .
-Hypervisor Support
-RBD supports the QEMU processor emulator and the Kernel-based Virtual Machine (KVM) virtualization infrastructure for the Linux kernel. Normally, these hypervisors would not be used together in a single configuration.
+======================Hypervisor Support======================
+RBD supports the QEMU processor emulator and the Kernel-based Virtual Machine (KVM) virtualization infrastructure for the Linux kernel. Normally, these hypervisors would not be used
+together in a single configuration.
KVM RBD
-The Linux Kernel-based Virtual Machine (KVM) RBD provides the functionality for striping data across multiple distributed RADOS objects for improved performance. KVM-RDB is supported for Linux kernels 2.6.37 and higher. Each RDB device contains a directory with files and information.
+The Linux Kernel-based Virtual Machine (KVM) RBD provides the functionality for striping data across multiple distributed RADOS objects for improved performance.
+KVM-RDB is supported for Linux kernels 2.6.37 and higher. Each RDB device contains a directory with files and information.
KVM employs the XEN hypervisor to manage its virtual machines.
QEMU RBD
-QEMU-RBD facilitates striping a VM block device over objects stored in the Ceph distributed object store. This provides shared block storage to facilitate VM migration between hosts. QEMU has its own hypervisor which interfaces with the librdb user-space library to store its virtual machines
+QEMU-RBD facilitates striping a VM block device over objects stored in the Ceph distributed object store. This provides shared block storage to facilitate VM migration between hosts.
+QEMU has its own hypervisor which interfaces with the librdb user-space library to store its virtual machines
.. _monitor:
--- /dev/null
+ <big>About this Document</big>
+This document contains planning and implementation procedures for Ceph. The audience for this document includes technical support personnel, installation engineers, system administrators, and quality assurance.
+<B>Prerequisites<b>
+Users of this document must be familiar with Linux command line options. They must also be familiar with the overall Ceph product.
+Before You Begin
+Before implementing a new Ceph System, first answer the questions in the Ceph Getting Started Guide to determine your configuration needs. Once you have determined your hardware and configuration needs, the following decisions must be made:
+\95 Determine what level of technical support you need. Pick from the Ceph Technical Support options in the next section.
+\95 Determine how much and what level of training your organization needs.
+Ceph Technical Support Options
+The Ceph Technical support model provides 4 tiers of technical support options:
+1st \96 This option is for brand new customers that need installation, configuration, and setup on their production environment.
+2nd \96 This level of support requires a trouble ticket to be generated on a case by case basis as customer difficulties arise. Customers can choose between two maintenance options; they can either purchase a yearly maintenance contract, or pay for each trouble resolution as it occurs.
+3rd \96 This option comes with our bundled packages for customers who have also purchased our hosting plans. In this case, the customer is a service provider. The Help Desk can generally provide this level of incident resolution. (NEED MORE INFO)
+4th \96 This level of support requires a Service Level Agreement (SLA) between the customer and Dreamhost. This level is used for handling the most difficult or advanced problems.
+Planning a Ceph Cluster Configuration
+The following section contains guidelines for planning the deployment for a Ceph cluster configuration. A Ceph cluster consists of the following core components:
+\95 Monitors \96 These must be an odd number, such as one, three, or five. Three is the preferred configuration.
+\95 Object Storage Devices (OSD) \96 used as storage nodes
+\95 Metadata Servers (MDS)
+For redundancy, you should employ several of these components.
+Monitors
+The monitors handle central cluster management, configuration, and state.
+Hardware Requirements:
+\95 A few gigs of local disk space
+\95 A fixed network address
+ Warning: Never configure 2 monitors per cluster. If you do, they will both have to be up all of the time, which will greatly degrade system performance.
+Object Storage Devices
+The OSDs store the actual data on the disks. A minimum of two is required.
+Hardware Requirements:
+\95 As many disks as possible for faster performance and scalability
+\95 An SSD or NVRAM for a journal, or a RAID controller with a battery-backed NVRAM.
+\95 Ample RAM for better file system caching
+\95 Fast network
+ Metadata Servers
+The metadata server daemon commands act as a distributed, coherent cache of file system metadata. They do not store data locally; all metadata is stored on disk via the storage nodes.
+Metadata servers can be added into the cluster on an as-needed basis. The load is automatically balanced. The max_mds parameter controls how many cmds instances are active. Any additional running instances are put in standby mode and can be activated if one of the active daemons becomes unresponsive.
+Hardware Requirements:
+\95 Large amount of RAM
+\95 Fast CPU
+\95 Fast (low latency) network
+\95 At least two servers for redundancy and load balancing
+TIPS: If you have just a few nodes, put cmon, cmds, and cosd on the same node. For moderate node configurations, put cmon and cmds together, and cosd on the disk nodes. For large node configurations, put cmon, cmds, and cosd each on their own dedicated machine.
+
--- /dev/null
+ <big>About this Document</big>
+This document contains planning and implementation procedures for Ceph. The audience for this document includes technical support personnel, installation engineers, system administrators, and quality assurance.
+<B>Prerequisites<b>
+Users of this document must be familiar with Linux command line options. They must also be familiar with the overall Ceph product.
+Before You Begin
+Before implementing a new Ceph System, first answer the questions in the Ceph Getting Started Guide to determine your configuration needs. Once you have determined your hardware and configuration needs, the following decisions must be made:
+\95 Determine what level of technical support you need. Pick from the Ceph Technical Support options in the next section.
+\95 Determine how much and what level of training your organization needs.
+Ceph Technical Support Options
+The Ceph Technical support model provides 4 tiers of technical support options:
+1st \96 This option is for brand new customers that need installation, configuration, and setup on their production environment.
+2nd \96 This level of support requires a trouble ticket to be generated on a case by case basis as customer difficulties arise. Customers can choose between two maintenance options; they can either purchase a yearly maintenance contract, or pay for each trouble resolution as it occurs.
+3rd \96 This option comes with our bundled packages for customers who have also purchased our hosting plans. In this case, the customer is a service provider. The Help Desk can generally provide this level of incident resolution. (NEED MORE INFO)
+4th \96 This level of support requires a Service Level Agreement (SLA) between the customer and Dreamhost. This level is used for handling the most difficult or advanced problems.
+Planning a Ceph Cluster Configuration
+The following section contains guidelines for planning the deployment for a Ceph cluster configuration. A Ceph cluster consists of the following core components:
+\95 Monitors \96 These must be an odd number, such as one, three, or five. Three is the preferred configuration.
+\95 Object Storage Devices (OSD) \96 used as storage nodes
+\95 Metadata Servers (MDS)
+For redundancy, you should employ several of these components.
+Monitors
+The monitors handle central cluster management, configuration, and state.
+Hardware Requirements:
+\95 A few gigs of local disk space
+\95 A fixed network address
+ Warning: Never configure 2 monitors per cluster. If you do, they will both have to be up all of the time, which will greatly degrade system performance.
+Object Storage Devices
+The OSDs store the actual data on the disks. A minimum of two is required.
+Hardware Requirements:
+\95 As many disks as possible for faster performance and scalability
+\95 An SSD or NVRAM for a journal, or a RAID controller with a battery-backed NVRAM.
+\95 Ample RAM for better file system caching
+\95 Fast network
+ Metadata Servers
+The metadata server daemon commands act as a distributed, coherent cache of file system metadata. They do not store data locally; all metadata is stored on disk via the storage nodes.
+Metadata servers can be added into the cluster on an as-needed basis. The load is automatically balanced. The max_mds parameter controls how many cmds instances are active. Any additional running instances are put in standby mode and can be activated if one of the active daemons becomes unresponsive.
+Hardware Requirements:
+\95 Large amount of RAM
+\95 Fast CPU
+\95 Fast (low latency) network
+\95 At least two servers for redundancy and load balancing
+TIPS: If you have just a few nodes, put cmon, cmds, and cosd on the same node. For moderate node configurations, put cmon and cmds together, and cosd on the disk nodes. For large node configurations, put cmon, cmds, and cosd each on their own dedicated machine.
+
--- /dev/null
+About this Document
+This document contains procedures for a new customer to configure a Ceph System.
+Before You Begin
+Before you begin configuring your system for Ceph, use the following checklist to decide what type of system you need.
+1. Identify the amount of storage that you need based on your current data, network traffic, workload, and other parameters
+2. Identify the growth potential for your business so that you can project ahead for future storage needs.
+3. Plan ahead for redundancy and replacement options.
+4. Study market forecasts and how they affect your business.
+Preparing a Ceph Cluster
+A Ceph cluster consists of the following core components:
+1. Monitors \96 These must be an odd number, such as one, three, or five. Three is the preferred configuration.
+2. Object Storage Devices (OSD) \96 used as storage nodes
+3. Metadata Servers (MDS)
+Although Ceph is extremely scalable, and nodes can be added any time on an as-needed basis, it is important to first determine the base needs of your configuration prior to setting up your system. This will save time and money in the long run. The following table offers a guideline on how many components your business should obtain prior to configuring your Ceph Cluster.
+Size/Workload Monitors OSD MDS Bandwidth
+Small/low 1 10 0-1 ???
+Small/average 3 23 1-3 ???
+Small/high 3 or more 30 3-5 ???
+Medium/low 3 20 1 ???
+Medium/average 3 30 1-3 ???
+Medium/high 3 or more 1000 3-5 ???
+Large/low 3 30 1 ???
+Large/average 3 or more 50 1-3 ???
+Large/high 3 or more 2000 3-10 ???
+ Warning: If you are using a low bandwidth system, and are connecting to the cluster over the internet, you must use the librados object level interface, and your OSDs must be located in the same data center.
+Sample Configuration
+The figure below shows a sample Ceph Configuration.
+img cephconfig.jpg
+
+Related Documentation
+Once you have determined your configuration needs, make sure you have access to the following documents:
+\95 Ceph Installation and Configuration Guide
+\95 Ceph System Administration Guide
+\95 Ceph Troubleshooting Manual
+
+
-==================================
- Internal developer documentation
-==================================
-
-.. note:: If you're looking for how to use Ceph as a library from your
- own software, please see :doc:`/api/index`.
-
-You can start a development mode Ceph cluster, after compiling the source, with::
-
- cd src
- install -d -m0755 out dev/osd0
- ./vstart.sh -n -x -l
- # check that it's there
- ./ceph health
-
-.. todo:: vstart is woefully undocumented and full of sharp sticks to poke yourself with.
+ About this Document
+This document contains planning and implementation procedures for Ceph. The audience for this document includes technical support personnel, installation engineers, system administrators, and quality assurance.
+Prerequisites
+Users of this document must be familiar with Linux command line options. They must also be familiar with the overall Ceph product.
+Before You Begin
+Before implementing a new Ceph System, first answer the questions in the Ceph Getting Started Guide to determine your configuration needs. Once you have determined your hardware and configuration needs, the following decisions must be made:
+\95 Determine what level of technical support you need. Pick from the Ceph Technical Support options in the next section.
+\95 Determine how much and what level of training your organization needs.
+Ceph Technical Support Options
+The Ceph Technical support model provides 4 tiers of technical support options:
+1st \96 This option is for brand new customers that need installation, configuration, and setup on their production environment.
+2nd \96 This level of support requires a trouble ticket to be generated on a case by case basis as customer difficulties arise. Customers can choose between two maintenance options; they can either purchase a yearly maintenance contract, or pay for each trouble resolution as it occurs.
+3rd \96 This option comes with our bundled packages for customers who have also purchased our hosting plans. In this case, the customer is a service provider. The Help Desk can generally provide this level of incident resolution. (NEED MORE INFO)
+4th \96 This level of support requires a Service Level Agreement (SLA) between the customer and Dreamhost. This level is used for handling the most difficult or advanced problems.
+Planning a Ceph Cluster Configuration
+The following section contains guidelines for planning the deployment for a Ceph cluster configuration. A Ceph cluster consists of the following core components:
+\95 Monitors \96 These must be an odd number, such as one, three, or five. Three is the preferred configuration.
+\95 Object Storage Devices (OSD) \96 used as storage nodes
+\95 Metadata Servers (MDS)
+For redundancy, you should employ several of these components.
+Monitors
+The monitors handle central cluster management, configuration, and state.
+Hardware Requirements:
+\95 A few gigs of local disk space
+\95 A fixed network address
+ Warning: Never configure 2 monitors per cluster. If you do, they will both have to be up all of the time, which will greatly degrade system performance.
+Object Storage Devices
+The OSDs store the actual data on the disks. A minimum of two is required.
+Hardware Requirements:
+\95 As many disks as possible for faster performance and scalability
+\95 An SSD or NVRAM for a journal, or a RAID controller with a battery-backed NVRAM.
+\95 Ample RAM for better file system caching
+\95 Fast network
+ Metadata Servers
+The metadata server daemon commands act as a distributed, coherent cache of file system metadata. They do not store data locally; all metadata is stored on disk via the storage nodes.
+Metadata servers can be added into the cluster on an as-needed basis. The load is automatically balanced. The max_mds parameter controls how many cmds instances are active. Any additional running instances are put in standby mode and can be activated if one of the active daemons becomes unresponsive.
+Hardware Requirements:
+\95 Large amount of RAM
+\95 Fast CPU
+\95 Fast (low latency) network
+\95 At least two servers for redundancy and load balancing
+TIPS: If you have just a few nodes, put cmon, cmds, and cosd on the same node. For moderate node configurations, put cmon and cmds together, and cosd on the disk nodes. For large node configurations, put cmon, cmds, and cosd each on their own dedicated machine.
.. toctree::
projects / ceph.git / commitdiff