放置组数配置
# ceph osd pool create {pool-name} pg_num
必须选择
pg_num的值，因为它（当前）无法自动计算。以下是一些常用值：
- 少于
5 OSDs设置pg_num为128 5-10 OSDs设置pg_num为51210-50 OSDs设置pg_num为1024- 如果您有超过
50个OSD，则需要使用pgcalc 计算pg_num值
(OSDs * 100)
Total PGs = ------------
pool size
结果应始终四舍五入到最接近的二次方,只有2的幂才能平衡放置组中对象的数量。其他值将导致数据在您的
OSD中的不均匀分布。
例如，对于具有200个OSD和3个副本的池大小的群集，您可以按以下方式估计PG的数量：
(200 * 100)
----------- = 6667. 最接近该数值的2的幂等为8192
3
放置组解析
放置组（PG）聚合池中的对象，因为在每个对象的基础上跟踪对象放置和对象元数据在计算上非常昂贵， 即，具有数百万个对象的系统无法在每个对象的基础上真实地跟踪放置。
Ceph客户端将计算对象应该在哪个放置组中。它通过散列对象ID并基于定义池中pg的数量和池的ID应用一个操作来实现这一点
放置组中的对象内容存储在一组OSD中。例如，在大小为2的复制池中，每个放置组将在两个OSD上存储对象.
如果OSD#2失败，另一个将被分配到放置组#1，并将填充OSD#1中所有对象的副本。如果池大小从2更改为3，则会为放置组分配一个附加的OSD，并接收放置组中所有对象的副本。
放置组不拥有OSD,它们与来自同一池甚至其他池的其他放置组共享OSD。如果OSD#2失败，放置组#2还必须使用OSD#3还原对象的副本。
当放置组的数量增加时，新的放置组将被分配OSD。挤压功能的结果也将更改，以前放置组中的某些对象将复制到新放置组中，并从旧放置组中删除。
放置组权衡
数据持久性和所有OSD之间的均匀分布需要更多的放置组，但是它们的数量应该减少到最小以节省CPU和内存。
数据持久性
单个OSD故障后，数据丢失的风险会增大，直到其中包含的数据被完全恢复。让我们想象一个场景，在单个放置组中导致永久的数据丢失:
OSD故障（可看作磁盘故障），包含对象的所有副本丢失。对于放置组内的所有对象，副本的数量突然从3个下降到2个。Ceph通过选择一个新的OSD来重新创建所有对象的第三个副本，从而开始恢复此放置组。- 同一放置组中的另一个
OSD在新OSD完全填充第三个拷贝之前失败。一些对象将只有一个幸存的副本。 Ceph会选择另一个OSD，并继续复制对象，以恢复所需的副本数量。- 同一放置组中的第三个
OSD在恢复完成之前失败。如果此OSD包含对象的唯一剩余副本，则它将永久丢失。
在一个包含10个OSD、在3个复制池中有512个放置组的集群中，CRUSH将给每个放置组三个OSD。
最终，每个OSD将托管(512 * 3)/ 10 ~= 150个放置组。
因此，当第一个OSD失败时，上述场景将同时启动所有150个安置组的恢复。
正在恢复的150个安置组可能均匀地分布在剩余的9个OSDs上。
因此，每个剩余的OSD都可能向其他所有OSD发送对象副本，并接收一些新对象来存储，因为它们成为了新的放置组的一部分。
完成此恢复所需的时间完全取决于Ceph集群的体系结构。假设每个OSD由一台机器上的1TB SSD托管，
所有这些OSD都连接到10Gb/s交换机，单个OSD的恢复在M分钟内完成。
如果每台机器有两个OSD、没有SSD、1Gb/s交换机，它至少会慢一个数量级。
在这种大小的集群中，放置组的数量对数据持f久性几乎没有影响。它可能是128或8192，恢复不会慢或快。
但是，将同一个Ceph集群增加到20个OSD而不是10个OSD可能会加快恢复速度，从而显著提高数据持久性。
每个OSD现在只参与~75个放置组，而不是在只有10个OSD时参与~150个，而且仍然需要剩下的19个OSD执行相同数量的对象副本才能恢复。
但是，以前10个OSD每个必须复制大约100GB，现在它们每个必须复制50GB。
如果网络是瓶颈，那么恢复的速度将是现在的两倍。换句话说，当OSDs的数量增加时，恢复速度会更快。
如果这个集群增长到40个OSD，那么每个OSD只能承载35个放置组。
如果OSD故障，除非它被另一个瓶颈阻塞，否则恢复将继续加快。
但是，如果这个集群增长到200个OSD，每个OSD只能承载~7个放置组。
如果一个OSD故障，那么在这些放置组中最多21个OSD（7*3）之间会发生恢复：恢复所需的时间将比有40个OSD时的集群长，这意味着放置组的数量应该增加。
无论恢复时间有多短，第二个OSD都有可能在恢复过程中失败。
在上述10个osd集群中，如果其中任何一个失败，那么~17个放置组（即~150/9个正在恢复的放置组）将只有一个幸存副本。
如果剩余的8个OSD中的任何一个失败，那么两个放置组的最后一个对象很可能会丢失（即大约17/8个放置组，只恢复了剩余的一个副本）。
当群集的大小增加到20个osd时，由于丢失3个osd而损坏的放置组的数量会下降。
丢失的第二个OSD将降级~4（即恢复~75/19个放置组），而不是~17，并且丢失的第三个OSD只有在包含幸存副本的四个OSD之一时才会丢失数据。
换句话说，如果在恢复时间范围内丢失一个OSD的概率为0.0001%，则在具有10个OSD的集群中，丢失的概率从17×10×0.0001%变为具有20个OSD的集群中的4×20×0.0001%
简而言之，更多的osd意味着更快的恢复和更低的导致永久性丢失放置组的级联故障风险。就数据持久性而言，512或4096个放置组在少于50个osd的集群中大致相当。
池中的对象分布
理想情况下，对象均匀分布在每个放置组中。由于CRUSH计算每个对象的放置组，
但实际上不知道该放置组中的每个OSD中存储了多少数据，因此放置组的数量与OSD的数量之间的比率可能会显著影响数据的分布。
例如，如果在一个三副本池中有十个OSD的单个放置组，那么只会使用三个OSD，因为CRUSH没有其他选择。
当有更多的放置组可用时，对象更可能均匀地分布在其中。CRUSH还尽一切努力将osd均匀地分布在所有现有的放置组中。
不均匀的数据分布可能是由osd和放置组之间的比率以外的因素造成的。
由于挤压不考虑对象的大小，一些非常大的对象可能会造成不平衡。
假设100万个4K对象（总共4GB）均匀分布在10个OSD上的1024个放置组中。他们将在每个OSD上使用4GB/10=400MB。
如果将一个400MB对象添加到池中，则支持放置该对象的放置组的三个OSD将被400MB+400MB=800MB填充，而其他七个OSD将仅被400MB占用。
内存、CPU和网络使用情况
对于每个放置组，osd和mon始终需要内存、网络和CPU，甚至在恢复期间需要更多。通过在放置组中聚集对象来共享此开销是它们存在的主要原因之一。
最小化放置组的数量可以节省大量资源。