]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commitdiff
doc/rados: remove references to premium support from inktank.com
authorAlfredo Deza <adeza@redhat.com>
Wed, 21 Sep 2016 21:56:41 +0000 (17:56 -0400)
committerAlfredo Deza <adeza@redhat.com>
Thu, 22 Sep 2016 11:43:43 +0000 (07:43 -0400)
Signed-off-by: Alfredo Deza <adeza@redhat.com>
doc/rados/operations/data-placement.rst

index 660df4fe14d222b5d297e93e7fc9fee0787e5740..27966b0dd98ac4e03dd18e101d1cf33daaf83ac4 100644 (file)
@@ -5,35 +5,33 @@
 Ceph stores, replicates and rebalances data objects across a RADOS cluster
 dynamically.  With many different users storing objects in different pools for
 different purposes on countless OSDs, Ceph operations require some data
-placement planning.  The main data placement planning concepts in Ceph include: 
+placement planning.  The main data placement planning concepts in Ceph include:
 
 - **Pools:** Ceph stores data within pools, which are logical groups for storing
   objects. Pools manage the number of placement groups, the number of replicas,
   and the ruleset for the pool. To store data in a pool, you must have
-  an authenticated user with permissions for the pool. Ceph can snapshot pools. 
+  an authenticated user with permissions for the pool. Ceph can snapshot pools.
   See `Pools`_ for additional details.
-  
-- **Placement Groups:** Ceph maps objects to placement groups (PGs). 
+
+- **Placement Groups:** Ceph maps objects to placement groups (PGs).
   Placement groups (PGs) are shards or fragments of a logical object pool
-  that place objects as a group into OSDs. Placement groups reduce the amount 
-  of per-object metadata when Ceph stores the data in OSDs. A larger number of 
-  placement groups (e.g., 100 per OSD) leads to better balancing. See 
+  that place objects as a group into OSDs. Placement groups reduce the amount
+  of per-object metadata when Ceph stores the data in OSDs. A larger number of
+  placement groups (e.g., 100 per OSD) leads to better balancing. See
   `Placement Groups`_ for additional details.
 
-- **CRUSH Maps:**  CRUSH is a big part of what allows Ceph to scale without 
-  performance bottlenecks, without limitations to scalability, and without a 
-  single point of failure. CRUSH maps provide the physical topology of the 
-  cluster to the CRUSH algorithm to determine where the data for an object 
-  and its replicas should be stored, and how to do so across failure domains 
+- **CRUSH Maps:**  CRUSH is a big part of what allows Ceph to scale without
+  performance bottlenecks, without limitations to scalability, and without a
+  single point of failure. CRUSH maps provide the physical topology of the
+  cluster to the CRUSH algorithm to determine where the data for an object
+  and its replicas should be stored, and how to do so across failure domains
   for added data safety among other things. See `CRUSH Maps`_ for additional
   details.
-  
+
 When you initially set up a test cluster, you can use the default values. Once
 you begin planning for a large Ceph cluster, refer to pools, placement groups
-and CRUSH for data placement operations. If you find some aspects challenging,
-`Inktank`_ provides excellent  premium support for Ceph.
+and CRUSH for data placement operations.
 
 .. _Pools: ../pools
 .. _Placement Groups: ../placement-groups
 .. _CRUSH Maps: ../crush-map
-.. _Inktank: http://www.inktank.com
\ No newline at end of file