Yjytianti 河南某银行 系统工程师
feng5371 某银行 云计算研发工程师
Smltc 乌海银行 CTO
【难点1】私有云建设过程中，可能引入多个云厂商，如何进行多云的统一化，集中化管理？
feng5371 某股份银行 云计算研发工程师：
并不建议引入过多不同厂家的云平台产品同时使用，这样会带来很高的管理和兼容成本，各家有各家的产品设计和约束，很难用一套统一的多云管理平台实现多品牌云平台 的统一无缝和谐管理，市面上应该基本没有这样的现成商业产品。如果无法改变厂商多的现状，必须要兼容，那自研或定制符合自身需要的多云管理平台是可能的选择，但难度和成本都很高，需要自身具备足够雄厚的技术实力和人才队伍。站在长远的角度考虑，建议形成统一的私有云架构，PaaS和IaaS一体化融合是趋势，在产品选择时可重点考察这方面的兼容能力。
Robot9527 某股份制城商行 系统架构师：
在降本增效的大背景下，这个问题还是需要企业结合自身云环境建设历程及建设需求，平衡采购成本和管理成本，选择适合的技术栈和管理平台。
总体来说需要注意几点：
1.制定统一的多云战略和规划，明确各厂商的角色和职责，并确定其与现有IT基础设施的关系。
2.选择适合企业的多云管理工具或平台，多云管理平台可以帮助企业管理多个云环境，实现自动化部署、监控和管理。
3.统一云资源命名规范和标签体系，确保不同云厂商之间的资源能够被识别和区分。
4.建立跨云厂商的安全策略和合规性控制，以保障数据隐私和安全。
5.实现多云间的互操作性和集成性，例如通过API网关或中间件等方式，将不同云厂商的服务连接起来，以便于业务应用的开发和部署。
【难点2】私有云资源管理过程中，如何兼顾效率（快速交付）与成本（弹性供给）？
Robot9527 某股份制城商行 系统架构师：
在降本增效的大背景下，面对业务系统负载波动较大的情况，如何快速完成资源交付确实是一个挑战。以下是一些策略和方法：
1.自动化的资源调度
自动化伸缩：利用自动化工具根据预设的规则或监控指标（如CPU使用率、内存占用等）自动调整资源分配。这包括自动增加虚拟机实例来应对流量高峰，以及在低峰期减少实例数量。
预测分析：基于历史数据进行负载预测，提前做好资源准备。可以采用机器学习模型来提高预测准确性。
2.精细化的资源规划（容量管理）
容量规划：定期评估现有资源利用率，并结合未来业务增长预期进行合理的容量规划。
资源池化：将物理服务器上的资源进行池化处理，使得资源能够更灵活地被分配给需要的应用和服务。
3.容器化技术
微服务架构：采用微服务架构设计应用程序，使得各个服务可以根据实际需求独立扩展。
Kubernetes：使用Kubernetes这样的容器编排平台来管理容器化应用，它支持水平扩缩容、滚动更新等功能，非常适合动态环境下的资源管理。
4.按需采购硬件
模块化基础设施：构建一个可扩展的基础架构，允许按照实际需求逐步添加新的计算节点、存储单元等。
混合云策略：在私有云资源不足的情况下，可以通过混合云模式临时借用公有云资源来应对突发流量。
5.成本控制机制
预算编制：制定年度IT预算，并将成本分摊到各个部门或项目中，提高成本透明度。
细粒度计费：确保能够对每个部门甚至项目级别的消费情况进行追踪和分析，促进成本意识，减少资源浪费。
6.持续监控与优化
性能监控：持续监控系统性能，及时发现并解决瓶颈问题。
定期回顾：定期检查资源配置是否合理，是否存在过度配置的情况，并作出相应调整。
【难点3】私有云运维过程中，如何进行架构统筹规划？
三虎 中国邮政储蓄银行 系统运维工程师：
从已有的建设经验回头看，云底座就是一个大的资源池，在建设初期要考虑的核心问题是：
1.“池子”的大小问题，建多大最合适，这其实类似于单个业务系统在建设时的规划问题，既要能满足后续的业务增长需求，又不能建设得过大。
这里的业务增长，是说后续新增、扩容、改造的系统情况，信息化建设一般都会有一个大致的规划，从第二年计划建设的系统资源需求，来定底座资源池需要的资源数较为合适，以年为单位来规划，在成本控制上较好，另外对新技术的应用、更迭也能有较快的反应。
建设过大，主要是别一次性投入过多，因为信息化系统建设的需求是和市场行情、业务发展需求紧密相连的，留有足够的冗余就好，一口吃个胖子的想法是不可取的，毕竟现在挣钱难，花钱要精打细算。
2.架构选型，当前主流的私有云，商业版的VMware和基于开源OpenStack的国内的云厂商，选型时首先要考虑兼容问题，一是向上的软件兼容，二是向下的硬件兼容问题。
先说硬件，因为金融等领域面临国家的政策要求，xc化改造势在必行，私有云能够支持的硬件架构就很关键，这样看，VMware在国产芯片的支持力度上就比较吃亏了，外加又是国外产品，以后要用应该越来越难，还是提早转的好。
再说软件，其实云平台本身的兼容问题比较少了，不管商用的还是开源的，都迭代了这么多年，很成熟了。那就看谁家更好用一些，应该说是各有千秋。如果在二者都允许的前提下，对于小客户来说，VMware可能更容易上手，更加友好，管理灵活度更好，但还是说回来，前提是还能一直用……
楼上也有同仁提到了资源监控，那就要说说云平台在弹性扩、缩容的灵活度方面了，OS其实一般，VM更好一些，纯个人观点。
Robot9527 某股份制城商行 系统架构师：
私有云运维过程中的架构统筹规划是一个复杂但至关重要的任务，它需要综合考虑多个方面来确保系统的稳定性、安全性及可扩展性。这里提供一些建议：
1.虚拟化和容器融合
技术选型：首先确定采用哪种虚拟化技术和容器技术（如KVM、PVE、Ovirt等作为虚拟化；Docker、Kubernetes等用于容器）。选择时要考虑它们之间的兼容性以及对现有基础设施的支持程度。
资源管理：实现一个统一的资源管理层，能够同时管理和调度虚拟机与容器资源，提高资源利用率。
安全隔离：确保虚拟机之间以及容器间的严格隔离，防止安全漏洞扩散。
持续集成/部署(CI/CD)：利用CI/CD工具链促进快速迭代开发，并支持从虚拟机环境向容器环境平滑过渡。
2.云管平台兼容性
开放标准：优先选用遵循开放标准的解决方案，比如OpenStack，这样可以更好地与其他系统或服务进行集成。
API接口：所选云管平台是否提供了丰富且文档详尽的API接口，便于未来扩展或定制开发。
跨云支持：考虑到长期发展可能涉及多云战略，选择支持混合云或多云管理能力的平台。
3.信创改造
国产化替换：积极响应国家政策号召，逐步将关键软硬件替换为符合国家安全标准的国内产品。2027年，完成信创100%替代。
4.人工智能与自动化
智能运维(AIOps)：通过集成机器学习算法到运维流程中，实现问题预测、自动故障排除等功能，从而提升系统稳定性和运营效率。
智能化决策支持：基于大数据分析和AI技术提供更加精准的商业洞察力，帮助企业管理层做出更好的战略决策。
【难点4】批量化操作方面，私有云是否可以根据个性化配置？
Robot9527 某股份制城商行 系统架构师：
目前大多数私有云只能做到操作系统内基本的个性化配置，比如主机名、IP地址、DNS等配置，部分厂商支持Excel表格方式批量创建虚拟机。操作系统内软件部署或者参数配置通过云管平台调用编排软件进行实现。云管平台内集成的编排软件功能与专业编排软件对比还是有较大的差距。
三虎 中国邮政储蓄银行 系统运维工程师：
关于批量化操作，其实是想解决快速交付的事，除了建虚机外，能够配置虚机OS的环境及上层软件。
据了解，大部分个性化设置，主要通过cloud-init可以实现。
有不少云厂商，对cloud-init进行封装，提供修改主机名、配置静态地址、个性化配置等等功能。
【难点5】私有云如何进行容量规划？
Steven 某金融企业 IT顾问：
这个通常要基于实际部署的业务特征、资源可扩展能力、服务管理能力等综合考虑。
基于经验，节点规格不宜过小，可以32C/128G或64C/256G,磁盘空间2T 的虚拟机，物理机用128C/512G, 4-8T磁盘（Raid后磁盘空间不宜太小），配置规格通常也基于部署服务的需求。另外节点能否动态扩容，扩容消耗时间越多，资源冗余容量可以更小，否则必须保证意外情况下的资源容量。
服务配额规则则根据实际运行监控调整，初始往往不知道配置多少合适，通常会配置的比较大，运行一段时间后可以根据资源历史使用情况调整， 高峰流量资源需求不高于配额的70%。
资源容量规划可能需要过往长期资源使用的可观测数据，基于资源使用趋势、承载的服务和流量、未来需要承载的服务和流量等来确定。
很多人也提出通过超分等提高资源使用率，但这种方式我不建议。最好的方式是优化调度，动态调度减少资源碎片，但调度算法实现并不容易，所受的限制因素很多。是一个动态的多目标规划问题。
三虎 中国邮政储蓄银行 系统运维工程师：
关于资源规格的分配问题，如果学习到操作系统原理，可以拿操作系统内存管理来作类比。
像Linux操作系统使用buddy来管理内存，将可分配的内存空间按照一定的算法来切分成不同粒度的块，一般是PAGESIZE为起始（4KB或64KB），逐级翻倍增加。这样在分配时只要分配不同粒度的连续页块即可，如用户申请6KB，那分配2KB+4KB的页块即可。
这样做的好处是提高内存分配和回收的效率，同时减少内存碎片化。
说回到咱们的资源分配，首先楼主提到的资源类型包括CPU、内存、磁盘、网络等，我们一个个的分析一下：
1.CPU和内存。内存一般是CPU核数的数倍（假设n），为了CPU和内存都能被同时利用，避免其中一种不够或者闲置，我们建议在定制虚机模型时按照服务器本身的CPU和内存比来设定。举例来说，一台物理机的可用core（含超线程后）有128个，内存512G，那么虚机模型建议内存：core = 4 ：1 ，当然这个比值只是大致的，不一定特别精确，在一些时候，云平台层面看到的可用cpu数量和内存数量会有缩减（因计算方式或预留等原因）。
另外CPU一般较少，所以分档模型的CPU数量应该是总CPU的1/2、1/4、1/8 …… 这样分配虚机时，保证剩余的资源足够创建一个小模型的虚机，比如128 core的主机，最后剩余16c也还是可以创建一个虚机的。
2.磁盘。磁盘一般多为外接磁盘，要么是分布式或者集中式存储，这带来的好处是，分配时不会造成剩余空间不可用，那么划分磁盘从管理方便的角度考虑，一般以100G为单位进行分配。
3.网络。因为网络IO波动较大，如果做配额管理，使用防火墙等手段控制，估计对性能有一定损耗，如果的确需要给虚机独享网络IO，可能是关键类业务的虚机，或者是大IO的批量处理类虚机，完全可以在虚机规划时，将这些虚机分配到单独的计算节点上，而不用对整个云平台再配置。
feng5371 某股份银行 云计算研发工程师：
上云系统的规格 ，一般指单个pod的配置和总的副本数。对于副本数，一般建议测试环境不限制，生产环境须不小于2。对于单个pod的配置，有两种做法可参考：
1.在一定范围内不限制单pod的规格（CPU和内存），由用户自定义。并建议可有几个约定，一是单pod最大资源配置不超过容器云平台计算节点容量的一定比例（比如30%），二是request默认为limit的一定比例（比如20%），三是通过性能测试确定单pod的最优资源配置和副本数。这种做法给了用户充分的自由度，也能充分利用资源，减少资源浪费。但对容器云平台运维方要求高，需要建立良好的容器云平台资源池监控和告警机制，可快速扩容，并使资源池保有一定的冗余量，以应对可能发生的业务量突增，。
2.固定几个pod规格（比如2C4G、4G8G等）供用户选择，如要突破需单独申请。这种做法便于运维方管理，但会带来一定量的资源浪费，一定范围内增加容器云平台的资源成本投入。具体哪种方做法适合己方单位，还需根据自身条件综合评估。
对于磁盘，建议应用系统将日志接入到日志中心，业务文件保存到文件平台或数据库，其他一般不特别限制pod使用宿主机磁盘空间。
【难点6】基于私有云如何进行容器云的架构规划部署？
Steven 某金融企业 IT顾问：
私有云上部署容器云需要考虑私有云能支持的容器网络模式，可能会跟容器云厂商的网络模型有关,另外可能需要考虑多集群和是否跨数据中心、跨网络安全域访问等问题，也就是企业是否存在严格的网络安全域，跟容器云注册发现中心部署、配置中心部署等可能都有关系。
私有云如果仅在一个安全域，相对就简单很多。
还有可能就是容器上部署的服务的灾备、不同level高可用的问题。
虚拟化一层性能肯定要差些，可观测性如果无法打通，底层私有云就是个黑盒，出现私有云故障等情况下会比较麻烦些，不过在实现资源弹性时可能简单很多。
三虎 中国邮政储蓄银行 系统运维工程师：
容器云在部署上，相比前期云平台底座的部署，相对要简化一些了。
容器云在网络方面和云部署有所差异，在主机层面和网络环境配置上，都要沟通清楚，并提前做好规划。
容器如果建在虚机上，则会有虚拟化的损耗，建议直接部署在物理机（裸金属），提高性能。
【难点7】私有云上业务系统数据如何备份及恢复？
Steven 某金融企业 IT顾问：
1.建议采购部署专业的备份恢复工具，不同架构的云和系统备份方式可能是不一样的，另外也需要考虑数据备份的合规要求等因素。
2.备份的数据也需要区分，研发数据、业务运营数据、系统运行数据、审计数据等备份策略和存储方式、地点可能都不一样。
建议基于实际合规等要求、分类分级通过专业的工具定义备份策略，完成备份，恢复时也能通过工具快速恢复。
Robot9527 某股份制城商行 系统架构师：
在私有云环境中，确保业务系统的数据备份及恢复能力是至关重要的。对于多品牌、多架构的私有云环境来说，制定有效的数据保护策略尤为关键：
1.备份软件支持多平台兼容
选择跨平台解决方案：寻找能够支持多种操作系统（如Windows、Linux等）、虚拟化平台（如VMware、KVM等）以及容器技术（如Docker、Kubernetes）的备份软件。
应用程序一致性：确保所选备份工具可以实现应用程序级别的备份，比如数据库（MySQL、Oracle等）和邮件服务器的一致性快照。
文件系统与对象存储：考虑到不同的存储需求，备份方案也应能处理传统文件系统及现代的对象存储服务。
备份存储分层：在线、近线、离线数据存储选择合适的方案节省成本。
2.根据业务场景配置不同的备份策略
定期全量与增量/差异备份：根据数据的重要性和变化频率设定合理的全量备份周期，并结合每日或更频繁的增量或差异备份以减少存储占用。
RPO与RTO定义：明确恢复点目标(RPO)和恢复时间目标(RTO)，据此调整备份频率和方式。对核心业务应用可能需要更短的RPO/RTO。
数据加密与压缩：为保障安全并节省空间，备份过程中应当启用数据加密功能，并尽可能利用压缩技术来减小传输和存储成本。
3.多中心部署业务实现DR容灾
异地复制：通过网络将重要数据同步到另一个地理位置的数据中心，这不仅有助于防范自然灾害，也能应对局部故障导致的服务中断。
冷热站点规划：根据实际情况决定采用热站（始终保持运行状态）、温站（部分资源常开，其余可快速启动）还是冷站（仅提供基础设施，需较长准备时间）作为灾难恢复计划的一部分。
定期演练：制定详尽的灾难恢复流程，并定期组织模拟演练，检验现有方案的有效性及团队响应速度。
监控与报警：建立完善的监控体系，实时追踪备份任务的状态，一旦发现问题立即通知相关人员采取措施。
4.其他考虑因素
长期保留策略：对于法规遵从性要求较高的行业，还需考虑如何经济有效地保存多年的历史记录。
自动化管理：尽可能利用自动化工具简化日常操作，包括但不限于备份作业调度、介质轮换以及过期数据清理等。
持续评估与优化：随着业务发展和技术进步，原有的备份恢复策略也需要相应调整，保持其有效性。
smltc 乌海银行 CTO：
传统来说，银行的数据备份建议采购部署专业的备份恢复工具，不同的业务系统备份要求不一样，在涉及交易的业务系统层面，建议每日备份一个全量备份，在报表级业务管理类系统中建议每月全量备份一次，每周/日增量备份一次，保留最近的12月的全量备份。
对研发数据、业务运营数据 ，应根据业务实际要求设置备份策略。建议不要超过每周一次全量备份。
1.安全合规要求高
2.高可用性和可靠性需求
3.系统集成复杂性
4.环境管理难度大
5.安全管理挑战大
6.人员技能要求高
如有任何问题，可点击文末阅读原文，到社区原文下评论交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 "私有云" 技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。地址：http://www.talkwithtrend.com/Topic/4315
*本公众号所发布内容仅代表作者观点，不代表社区立场
