01 超融合平台中的数据是否需要独立的放在外置存储上？
@超融合产品经理：
完全没必要，因为超融合的核心之一就是分布式存储，对于专业厂商提供的超融合产品，分布式块存储都有类似副本的技术，保证硬盘和节点在冗余度之内的损坏数据都不会丢失 。
如果是用在生产环境里，基于数据可靠性的考虑，需要独立的备份系统用于保护数据，防止因为误删除外部因素导致的数据损坏和丢失，这不是针对超融合系统，因为无论多么高端的存储，备份都是不可替代的。
如果是更高级别的数据可用性，比如同城双活，需要购买对应的软件模块或者配备第三方的方案。现在vSAN都是自带双活功能的。
02 超融合服务器是什么？和超融合一体机什么区别？
@超融合产品经理：
首先，超融合是近几年兴起的一种新的 IT 基础架构，这种架构具备以下特点：
符合软件定义数据中心理念，一定是通过软件结合标准的 x86 服务器来构建分布式存储，而不使用基于定制硬件的传统集中式存储；
这个概念强调的是分布式存储软件和虚拟化软件的融合部署，并不是单纯的指软、硬件融合。
基于这种架构，厂商给用户提供的产品形态一般有两种：
1.超融合软件。用户可以基于超融合软件和自己选定的 x86 服务器硬件构建超融合基础架构；
2.超融合一体机。厂商根据客户的需求，和自身的产品策略，为用户提供的开箱即用，一体机化的交付方式，一体机包含了软件和 厂商选定并适配的 x86 服务器。
那么超融合服务器是什么？目前市场上还会有“超融合服务器”这样的概念，这并不是一个标准的概念，其中包含两种可能：
1.就是指超融合一体机；
2.指支持超融合软件的服务器，而这类服务器，一般就是标准的 x86 服务器。
03 超融合三副本模式，能避免任意3块硬盘故障吗？节点故障时引起的数据复制对集群性能造成的影响，会不会影响生产系统性能？
@超融合产品经理：
题主的问题主要来自对超融合平台的数据可靠性方面的质疑，我们可以围绕这两个问题进行一下探讨。
a. 三副本是否能允许任意 3 块硬盘故障？
三副本是允许单一集群内部任意 2 块硬盘同时故障而不导致数据丢失的数据可靠性保护手段，也就是说无法允许任意 3 块硬盘同时故障。
这里有两个关键词，第一个是 “任意”，由于三副本是将数据写三份，强制分布在 3 台服务器上的不同硬盘之中，任意丢失 2 个副本，依然可以通过剩下的 1 个副本进行数据恢复，不会引发数据丢失，那就意味着如果故障硬盘都在同一个服务器上的话，即使多于 2 块硬盘也不会导致数据丢失，因为肯定可以在其他节点中有其他可用副本。第二个关键字是 “同时”，如果这个故障是先后发生也是不在限制范围，例如有 1 块硬盘故障，经过自动地数据恢复完成后，再次故障 2 块硬盘，这样也不会导致数据丢失的情况。
目前主流的超融合产品都是支持 2 副本 和 3 副本的，基本上没有更高级别的冗余，因为这样容量开销比较大，实际可用空间就太少了。
b. 当数据恢复的时候是否会影响现有生产环境性能？
首先触发数据恢复或者数据重构，动作本质上是发生存储读写 IO 的，它必然是占用一部分存储性能的。但是现在做得比较好的超融合产品，会自动控制单节点数据恢复的速度，利用多个节点进行并发恢复，这样既能在较短的时间窗口恢复数据可靠性级别，又能尽可能保障生产环境性能。另外超融合使用的副本技术与传统 raid 数据冗余保护有所不同，raid 组出现硬盘故障，是需要全盘数据重构的，无论这块盘是否写满数据甚至是基本是空的都要全盘数据恢复；而副本技术只会恢复写入的数据，某些情况下可以大幅减少数据恢复量，缩短数据恢复窗口，减少对生产环境的影响。
04 Ansible是否适合做自动化采集工作？如何与CMDB进行结合？
@企业级开源解决方案中心软件架构设计师：
某些客户数据中心已经实现了系统数据采集的应用场景，比如CPU，内存，磁盘容量，IO等参数的抓取。直接编写playbook即可，无需和CMDB对接。如果需要对接，可从CMDB从查询设备信息，然后去相应设备上抓取指定参数。实现需要详细讨论
05 Ansible系统损坏，对被管理系统有什么影响？
@企业级开源解决方案中心软件架构设计师：
损坏后如果playbook也对丢了影响比较大，如果数据没丢，可以重建然后重新建互信即可快速恢复。
生产环境下ansible以及tower的建设需要有高可用架构，对于tower的高可用架构，前端需要F5或者haproxy这些负载均衡器，后端的状态同步需要有postgresql 的replication多副本保证。
对于playbook的保护，最好有备份机制，或者放到代码库或者共享存储中。
06 上线新的对象存储平台，应该从哪些方面对新产品进行细致的测试？
@资深解决方案专家：
上新的存储系统都需要对存储平台进行稳定性，兼容性，性能，异常进行全方面测试。需要应用部门，技术部门一起协同测试。
比如：
兼容性——
需要与前端对象应用部门联合测试，通过API，脚本充分测试和对象存储的对接验证，并配合性能，稳定性持续测试。
性能——
对于对象存储来说，数据类型分为大对象，小对象。衡量对象存储性能是否满足业务需求，可以通过cosbench模拟4k 1M在大并发下存储性能表现，当然也要和业务进行对接测试，用业务系统真实跑一轮性能测试，在性能测试过程中也要进行稳定性测试，进行拔盘，断节点查看在异常的状态下存储性能表现。
稳定性——
长期跑IO测试集群性能。
07 Ceph一个OSD应该分配多少内存？
【问题描述】一个OSD应该分配多少内存？最近在测试Ceph集群，发现OSD占用的内存随着写入的数据越来越多，占用的内存也越来越多，最终都把系统内存完了。
root 31383 28.2 8.3 2593676 920976 ? Ssl Mar01 332:07 /usr/local/hstor/ceph_dir/美满的人生/ceph-osd -i 42 --pid-file /var/run/ceph/osd.42.pid -c /usr/local/hstor/ceph_dir/etc/ceph/ceph.conf --cluster ceph
root 32534 21.2 8.4 2591672 936432 ? Ssl Mar01 249:22 /usr/local/hstor/ceph_dir/美满的人生/ceph-osd -i 44 --pid-file /var/run/ceph/osd.44.pid -c /usr/local/hstor/ceph_dir/etc/ceph/ceph.conf --clust
@资深解决方案专家：
现在分配了多少内存出现问题了呢？Ceph 集群出现异常比如数据重平衡会大量使用内存， OSD 内存消耗通常与系统中每个守护进程的 PG 数有关。内存问题需要多注意，内存不够会导致 OSD 重启，集群异常。ceph.com 也给出了推荐的 OSD 内存配置，可以参考一下建议3-5GB吧。
OSDs (ceph-osd)
By default, OSDs that use the BlueStore backend require 3-5 GB of RAM. You can adjust the amount of memory the OSD consumes with the osd_memory_target configuration option when BlueStore is in use. When using the legacy FileStore backend, the operating system page cache is used for caching data, so no tuning is normally needed, and the OSD memory consumption is generally related to the number of PGs per daemon in the system.