主要看公司策略和监管要求,如果有信创任务,建议从非账务和非交易类应用先行使用,逐步积累经验,新创和非信创都建议选择商业和开源两个方向,如果技术方面可行也可以选择多个商业版本避免单一厂商依赖。
差别不大,日常运维主要涉及lvm,常用软件,软件包管理,ha配置,系统和内核参数调优等。但硬件兼容性和驱动的稳定性需要自行踩坑。建议管理类,监控类应用可以先行试点积累经验。
kylinv10,openEuler等等。
根据数据中心软硬件架构和技术栈做全方面测试,主要做整机,操作系统,存储,容器,中间件,数据库等兼容测试。如果有国产迁移的需求,除自行测试最好配合系统厂商进行兼容性评估。
由于各个公司业务系统特性不同,IT技术使用各异,很难有一个开箱即用的商业产品能满足要求,都需要在使用过程中总结需求和使用的痛点持续改进。正如问题所述,解决跨部门协调问题,降低沟通成本,直观展现切换流程,流程数据维护这
vmware虚拟化的srm方案类似您的方法,通过存储复制进行虚拟机文件同步,切换时进行存储角色切换并拉起虚拟机。如条件允许也可以考虑存储双活,如emc vplex方案,将容灾的工作交给存储负责,虚拟化层基本无感知。
RTO保障方面可以根据以往的灾备切换经验评估整体和各种场景的切换时间,如果RTO无法保证,可以将业务系统分模块切分,并行切换,同时保证现有模块直接的依赖关系,缩短RTO。在灾备建设初期就要进行容灾场景设计,容灾场景覆盖大
首先业务系统灾备投产时已经梳理了整个切换的流程步骤,并且通过灾备指挥平台调用切换成功。切换动作大概分为存储,操作系统,数据库,应用,网络五个部分。存储通过角色swap从主站点切换到灾备站点,操作系统涉及vg,fs,ip,ha等
存储复制技术目前比较稳定,能够保证RPO,存储双活技术也是灾备的未来方向;数据库方面有自身的复制技术,但是切换过程对技术要求较高。
目前API调用我们复用的是HP OPSWARE产品,但是本身有并发限制问题,其他的工具有saltstack ,ansible,puppet等,目前自动化运维等其他项目采用ansible.灾备切换涉及数据库,存储,应用等方面的动作,比如应用的启动,停止,状态检查。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30