当云服务器出现降级时，可能会对业务造成重大影响。降级可能是由多种因素造成的，包括但不限于：
- 硬件故障：服务器硬件故障会导致暂时或永久性数据丢失，从而导致服务中断。
- 软件故障：操作系统或应用程序的故障可能导致服务器崩溃或冻结，从而导致服务中断。
- 网络问题：网络连接问题，例如拥塞或中断，可能使服务器无法访问，从而导致服务中断。
- 安全漏洞：安全漏洞可能使服务器容易受到黑客攻击，从而导致数据泄露或服务中断。
为了最大程度地减少云服务器降级的影响，采用适当的应对策略至关重要。以下是专家建议的一些最佳实践：
1. 监控和预警
实时监控云服务器的性能可以帮助尽早发现潜在问题。设置预警以提醒您服务器性能下降，以便您可以立即采取行动。
2. 故障转移和备份
通过实施故障转移和备份策略，您可以确保在云服务器不可用时，业务仍然可以正常运行。故障转移是指将流量路由到
什么是不可变基础设施？
在可变基础设施中，服务器在部署后可以被更新和修改。
工程师和管理员可以SSH到服务器，手动升级或降级软件包版本，调整配置文件，并将新代码部署到现有服务器上。
然而，不可变基础设施则不同，它设计为服务器在部署后保持不变，通过修改公共镜像并使用镜像构建新服务器来实现更新或修复。
新服务器验证后投入使用，旧服务器则被下线。
这种模式提供了更多一致性与可靠性，简化了部署过程，同时可以防止常见的问题，如配置漂移和雪花服务器。
使用不可变基础设施需要全面的自动化部署、云计算环境中的快速服务器配置以及处理有状态数据或临时数据（如日志）的解决方案。
本文将更深入探讨可变和不可变基础设施的区别，以及它们在实践和概念上的差异。
重点在于虚拟化和云计算技术的发展如何使不可变基础设施成为可能，以及基于服务器的基础设施如何转变。
从概念上看，可变基础设施将服务器视为独一无二的“宠物”，而不可变基础设施则将服务器视为可复制的“牛”，强调自动化和快速替换。
不可变基础设施在概念上和实践上都与可变基础设施大相径庭。
它们在如何处理服务器（如创建、维护、更新、销毁）方面存在显著差异。
虚拟化和云计算技术的发展使得快速提供架构组件（如云计算的虚拟服务器）成为可能，这是不可变基础设施得以实现的关键。
随着技术的演进，可变基础设施最初是为了应对物理服务器昂贵且耗时的维护而发展起来的，而不可变基础设施则依赖虚拟化技术提供快速、高效和自动化的工作流程。
在概念上，可变基础设施中的服务器是不可替代的、必须始终保持运行的独特系统，而不可变基础设施中的服务器则是一次性的，易于使用自动化工具复制或扩展。
云计算的引入使得服务器可以视为一次性的资源，允许在出现问题时快速替换，从而减少了对特定服务器的依赖。
不可变基础设施中的服务器通常基于自动化流程构建，使得部署过程更简单、更可靠，并且能够轻松回滚或处理故障，提供一致的服务器状态。
与可变基础设施相比，不可变基础设施能够防止配置漂移和雪花服务器的问题，简化了水平扩缩容和预发布环境的管理，并提供了更易于处理的故障恢复机制。
实现不可变基础设施的关键组件包括CI/CD工具、数据库即服务（DBaaS）解决方案、集中日志记录系统以及用于随机测试生产环境的工具。
这些组件有助于实现自动化部署、快速替换服务器、集中管理和监控日志，以及通过随机测试确保系统的稳定性。
考虑迁移到不可变基础设施时，可以先从实现一些设计实践开始，如配置管理，即使在可变环境中工作。
这将有助于为未来全面采用不可变基础设施打下基础。
如果您现有的基础设施包含了上述组件，且遇到扩缩容困难或对部署过程不满意，那么开始评估如何利用不可变性改进基础设施是一个明智的选择。
通过从几个公司（如Codeship、Chef、Koddi和Fugue）获取更多信息，您可以了解到更多关于不可变基础设施的实现细节和最佳实践。
深信服成为国内首批一云多芯稳定性工作组成员
12月19日，中国信通院、混沌工程工作室举办“稳保行动”线上沙龙，会上正式宣布成立“一云多芯稳定性工作组”，深信服作为国内资深的云基础设施服务商，凭借在一云多芯稳定性方面的技术沉淀与产品积累，成功选入工作组首批成员单位。
深信服可靠性专家汤洪亮受邀出席了本次沙龙，并进行了《信服云系统稳定性》的演讲，基于系统稳定性建设分享了深信服的实践经验。
信服云“一云多芯”场景汤洪亮认为，近年来信创产业虽然发展快速，但信创产品从“能用”到“好用”仍然有一定的差距。
拿信服云的一云多芯稳定性工作来说，如何快速地兼容各类国产软硬件，建立一个稳定的软硬件生态?云平台如何在中间尽量发挥硬件最大性能?如何快速填补信创场景下的可靠性差距?这些都是需要不断解决和优化的问题。
汤洪亮介绍，信服云致力于打造兼容各种国产软硬件的可靠基础资源平台，帮助用户实现国产化软硬件的改造，发挥IT基础设施的优异性能，构建业务系统平稳运行的优质体验。
在性能调优上，信服云基于多年的现网运行经验，沉淀出各类的软硬件故障场景，并进行深度分析与专项改进。
包括使用FMEA方法分析产品级故障模式，沉淀800+个通用云故障模式，支持300+个信创OS软件及硬件测试场景;自研故障注入工具ChaosArsenal，提供200+个原子故障注入能力，可以发现并解决大部分集中在系统资源加压下的软硬件兼容性、软硬件结合导致的宕机等问题。
同时还支持X86、ARM架构下信创操作系统故障注入，包括硬件、操作系统、虚拟化、容器、中间件、业务等，覆盖度达到75%。
在体验创新上，信服云力求打造真正优质的“双栈”体验。
特别在“一云多芯”场景中，尽可能发挥出cpu和OS的性能潜力和调度能力，追求更大限度地屏蔽底层硬件体系的差异，并不是简单兼容性适配多cpu架构和多种操作系统的补丁式的“一云多芯”，做到不阉割功能、不妥协质量、不降级性能、不锁服务器，真正把用户体验做到双栈一致。
在信创生态建设上，信服云已与国内主流cpu、操作系统、中间件、数据库、办公OA、邮箱等应用完成全系列产品的深度适配，并在全国落地了1000+个信创安全、信创云项目实践，与60+信创生态伙伴达成战略合作共筑信创生态。
汤洪亮在演讲最后表示，信服云未来会继续在信创领域深耕，积极推进信创软硬件上下游生态的融合发展，持续打造信创性能和体验创新最佳实践，为用户提供使用更简单、体验更流畅的信创数字化解决方案。
「精心整理」Ceph搭建硬件建议详解
Ceph是专为在商品硬件上运行而设计的，这使得构建和维护超大规模的数据集群在经济上是可行的。
当规划出你的集群硬件时，你需要平衡一些考虑因素，包括故障域和潜在的性能问题。
硬件规划应该包括将Ceph守护进程和其他使用Ceph的进程分布在许多主机上。
一般来说，我们 建议在为该类型的守护进程配置的主机上运行特定的Ceph守护进程。
我们建议使用其他主机来处理使用您的数据集群的进程（例如OpenStack、CloudStack）
Ceph元数据服务器会动态地重新分配负载，这对CPU来说是很有必要的。
所以你的元数据处理器应该有相当大的处理能力（四核心或更高的CPU）。
Ceph OSDs 运行RADOS服务，用CRUSH计算数据放置、复制数据，并维护自己的集群地图副本。
因此，OSD应该有合理的处理能力（例如双核处理器）。
监视器只是维护集群映射的主副本，所以监视器不需要CPU密集型的处理能力。
除了Ceph守护进程之外，你还必须考虑主机是否会运行CPU密集型进程，例如，如果您的主机将运行计算虚拟机（例如，OpenStack Nova)，您需要确保这些其他进程为Ceph守护进程留下足够的处理能力。
我们建议在单独的主机上运行额外的CPU密集型进程。
一般来说，RAM越多越好
监视器和管理器守护进程的内存使用量一般会随着集群的大小而变化。
对于小型集群，一般来说，1-2GB就足够了。
对于大型集群，你应该提供更多（5-10GB）。
你可能还需要考虑调整设置，如mon_osd_cache_size或 rocksdb_cache_size
Bluestore使用自己的内存来缓存数据，而不是依赖操作系统的页面缓存。在BlueStore中，你可以通过osd_memory_target选项调整OSD_memory_target的内存量
•通常不建议将osd_memory_target设置为2GB以下，可能会将内存保持在2GB以下，同时也可能导致性能极慢。
•将内存目标设置在2Gb和4Gb之间通常有效，但可能会导致性能下降，因为元数据可能在IO期间从磁盘读取，除非活动数据集相对较小。
•4GB是目前默认的osd_memory_target大小，这样设置的目的是为了平衡内存需求和OSD的性能，以满足典型的使用情况•设置osd_memory_target高于4GB时，当有许多（小的）或大的（256GB/OSD)数据集被处理时，可能会提高性能。
重要：
OSD的内存自动调整是“尽力而为”。
虽然OSD可能会解除内存映射，让内核回收内存，但不能保证内核会在任何特定的时间框架内实际回收释放的内存。
这在旧版本的Ceph中尤其如此，因为透明的巨页会阻止内核从碎片化的巨页中回收内存。
现代版本的Ceph在应用级禁用透明巨页以避免这种情况，但这仍然不能保证内核会立即回收未映射的内存。
OSD有时仍然可能会超过它的内存目标。
我们建议在系统中保留20%左右的额外内存，以防止OSD在临时高峰期或由于内核延迟回收空闲页而导致的OSD出现OOM。
这个值可能会比需要的多或少取决于系统的具体配置。
在使用传统的FileStore后端时，页面缓存是用来缓存数据的，所以一般不需要调优，OSD的内存消耗一般与系统中每个守护进程的PG数量有关
仔细规划你的数据存储配置。
在规划数据存储时，需要考虑重大的成本和性能权衡。
同时进行操作系统操作，以及多个守护进程对单个驱动器同时请求读取和写入操作，会大大降低性能。
重要
由于Ceph在发送ACK之前必须先将所有数据写入日志（至少对XFS来说），所以日志和OSD的性能平衡真的很重要！在这里，Ceph的日志和OSD的性能是非常重要的。
OSD应该有足够的硬盘空间来存放对象数据。
我们建议硬盘驱动器的最小容量为1T。
考虑到较大磁盘的每GB的成本优势。
我们建议将硬盘驱动器的价格除以千兆字节，得出每千兆字节的成本，因为较大的驱动器可能会对每千兆字节的成本有很大影响。
例如，价格为75美元的1T硬盘，每千兆字节的成本为0.07美元。
相比之下，价格为150美元的3T硬盘的成本为每千兆字节0.05美元。
在上述例子中，使用1T硬盘通常会使每千兆字节的成本增加40%——使集群的成本效益大大降低。
Tips: 在一个磁盘上运行多个OSD，无论分区如何，都不是一个好主意
Tips: 在单一磁盘上运行OSD和显示器或者元数据服务器，无论分区如何，都不是一个好主意
存储驱动器在寻求时间、访问时间、读取和写入时间以及总吞吐量方面受到限制。
这些物理限制会影响整体系统性能，特别是在恢复期间。
我们建议为操作系统和软件使用一个专门驱动器，并且您在主机上运行的每个Ceph OSD daemon使用一个驱动器。
大多数“慢OSD”问题的出现是由于在同一个驱动器上运行一个操作系统，多个OSD，或多个日志。
由于在一个小型集群上排除性能问题的成本超过了额外的磁盘驱动器的成本，因此您可以通过避免过度消耗OSD存储驱动器的诱惑来优化您的集群设计规划。
您可以在每个硬盘驱动器上运行多个Ceph OSD Daemons，但这可能会导致资源征用，降低整体吞吐量。
你可以在同一硬盘上存储日志和对象数据，但这可能会增加写日志和ACK到客户端所需要的时间。
Ceph必须先写入到日志，然后再进行ACK写入。
ack写入：完成此类写入之后，将向客户端发送一个成功写入的ACK，所以称之为ACK写入
Ceph最佳实践规定，你应该在不同的驱动器上运行操作系统、OSD数据和OSD日志
提高性能的一个机会是使用固态硬盘来减少随机访问时间和读取延迟，同时加快吞吐量。
与机械硬盘相比，固态硬盘每千兆字节的成本往往超过10倍以上，但固态硬盘的访问时间往往比机械硬盘至少快100倍。
固态硬盘没有活动的机械部件，所以他们不一定会受到与机械硬盘相同的限制。
但固态硬盘确实有很大的局限性。
在评估固态硬盘时，重要的是考虑顺序读取和写入的性能。
当为多个OSD存储多个日志时，具有400MB/S顺序写入吞吐量的SSD可能比具有120MB/s顺序写入吞吐量的SSD性能要好的多。
重要
我们建议探索使用固态硬盘来提高性能。然而，在对SSD进行重大投资之前，我们强烈建议在审查SSD的性能指标和测试配置中测试SSD的性能
由于固态硬盘没有活动的机械部件，所以在Ceph中不需要使用大量存储空间的区域（如日志）使用固态硬盘是很有意义的。
相对便宜的SSD可能会吸引你的经济意识。
请谨慎使用。
在选择使用Ceph的SSD时，仅有可接受的IOPS是不够的。
日志和SSD有几个重要的性能注意事项：
•写入密集型语义：日志涉及到写密集型语义，因此您应该确保您选择部署的SSD在写入数据时的性能相当于或优于机械硬盘。
廉价的固态硬盘在加速访问时间的同时，可能会引入写入延时，因为有时高性能硬盘的写入速度会比市场上一些更经济的固态硬盘快，因此，您应该确保您选择的固态硬盘在写入数据时的性能与机械硬盘相当或更好。
•顺序写入：当您在SSD上存储多个日志时，您必须考虑到SSD的顺序写入限制，因为它们可能会同时处理对多个OSD日志的写入请求。
•分区对齐：SSD性能的一个常见问题是，人们喜欢将硬盘分区作为最佳做法，但往往忽略了对SSD的正确分区对齐，这样会导致SSD的数据传输速度更慢。
确保SSD分区正确对齐
虽然固态硬盘对于对象存储的成本较高，但通过将OSD的日志存储在固态硬盘上，并将OSD的对象存储存储在独立的机械硬盘上，可能会看到性能的显著提升。
osd journal配置设置默认为/var/lib/ceph/osd/$cluster-id/journal。
您可以将此路径挂载到SSD或者SSD分区，使其不只是与对象数据存储在同一硬盘上。
Ceph加速CephFS文件系统性能的一种方法是将CephFS元数据的存储与CephFS文件内容的存储隔离开来。
Ceph为CephFS元数据提供了一个默认的元数据池。
你永远不必为CephFS元数据创建一个池，但你可以为你的CephFS元数据池创建一个只指向主机的SSD存储介质的CRUSH映射层次结构。
详情请参见将池映射到不同类型的OSDs。
•意思是可以将一个池的所有数据都存储到SSD类型的OSD
磁盘控制器对写入吞吐量也有很大影响。
在选择磁盘控制器时要慎重考虑，确保不会造成性能瓶颈。
••你可以在每台主机上运行多个OSD，但你应该确保你的OSD硬盘的总吞吐量之和不超过服务于客户端读取或写入所需的网络带宽。
你还应该考虑集群在每台主机上存储的数据占整体数据的百分比。
如果某个特定主机上的百分比很大，而该主机出现故障，可能会导致超过 full ratio 等问题，从而导致Ceph停止工作，作为防止数据丢失的安全规范措施。
当你在每个主机上运行多个OSD时，你还需要确保内核是最新的。
请参阅OS建议中关于glibc和syncfs（2）的说明，以确保你的硬件在每个主机上运行多个OSD时，能按照预期的方式执行。
考虑从机架上的10Gbps+网络开始。
在1Gbps网络上复制1TB的数据需要3个小时，而10TB需要30个小时！相比之下，使用10Gbps网络，复制时间分别需要20分钟和1小时。
在petabyte规模的集群中，OSD磁盘的故障应该是一种预期，而不是例外。
在考虑到价格/性能权衡的情况下，系统管理员会很欣赏PG能尽快从降级状态恢复到活动+清洁状态。
此外，一些部署工具采用VLANS使硬件和网络布线更易于管理。
使用802.1q协议的运营成本节省所抵消。
当使用VLAN来处理集群和计算堆栈（例如OpenStack、CloudStack等）之间的VM流量时，也值得考虑10G以太网。
每个网络的架上路由器还需要能够与吞吐量更快的骨干路由器进行通信，例如40Gbps到100Gbps。
您的服务器硬件应该有一个底层管理控制器（BMC）。
管理和部署工具也可能会大量使用BMC，因此要考虑带外网络的管理成本/收益权衡。
Hypervisor SSH访问、VM镜像上传、操作系统镜像安装、管理套接字等都会给网络带来巨大的负载。
运行三个网络可能看起来似乎矫枉过正，但每个流量路径都代表了潜在的容量、吞吐量和/或性能瓶颈，在部署大规模数据集群之前，您应该仔细考虑。
BMC：Baseboard Management Controller，基板管理控制器
带外网络：OOB，全程Out Of Band，一套与任何业务数据网络没有关联的独立网络，在任何时候——即便是业务网络终端的情况下，网络控制中心都可以通过带外网络连接到各个服务器或者网络设备的管理接口或者console.
故障域是指任何阻止一个或多个OSD的故障。
这可能是主机上的守护进程停止；硬盘故障、操作系统崩溃、网卡故障、电源故障、网络中断、断电等等。
在规划硬件需求的时候，你必须平衡一下，把太多的责任放在太少的故障域中来降低成本，以及隔离每个潜在故障域所带来的额外成本
Ceph可以在廉价的商品硬件上运行。小型生产集群和开发集群可以用适中的硬件成功运行
进程类型硬件类型建议的最低标准
ceph-osd Processor最低一核200-500MB/s 单核心1000-3000IOPS 单核心结果是复制之前的结果结果可能会因为不同的CPU型号和Ceph功能而不同（纠删码池、压缩等）ARM处理器可能会需要更多的核心实际性能取决于许多因素，包括磁盘、网络、客户端吞吐量和延迟。我们强烈建议进行基准测试RAM每个守护进程4GB以上（越多越好）2-4GB 可以正常工作（可能会很慢）低于2GB是不推荐的Volume Storage每个守护进程对应一块硬盘DB/WAL每个守护进程对应一个SSD分区（可选）Network最少一块千兆以上的网卡（万兆网卡是被推荐的） ceph-mon Processor最低一核RAM每个进程2GB以上的内存Disk Space每进程10GB以上的硬盘空间Network最少一块千兆以上的网卡 ceph-mds Processor最低一核RAM每个进程2GB以上的内存Disk Space每个进程1MB以上的硬盘空间Network最少一块千兆以上的网卡
