由 dawei 在上一篇文章（可中心可边缘，云计算“罗马大路”需要什么样的超融合新基建？）中，介绍了Dell EMC VxRail E系列超融合的硬件平台，使用单路AMD EPYC 7502P处理器，尽管是单路处理器，但7502P处理器具有32核心，64线程，并有128MB的L3缓存，以及8通道DDR4-3200MHz内存（最多16条），性能并不输于主流双路服务器，甚至性能更好；同时这款处理器支持128条PCIe 4.0通道，使得其可扩展性也超过了主流的双路服务器。
更重要的是，Dell EMC通过其强大的设计能力，让AMD EPYC7502P处理器不仅能够充分发挥出强大的计算性能，同时也具有极其灵活的可扩展性。
对于企业用户而言，强大灵活扩展的硬件平台只是必备条件，更重要的是运维与管理能力。那么作为超融合市场的“王者”，VxRail是如何帮助用户实现简单高效管理的呢？
集群视角 全生命周期管理
超融合基础设施从诞生之初就被赋予了构建新型数据中心的使命，其最大的特点就是“软件定义”软件定义计算、软件定义存储以及软件定义网络，前两者属于必备，软件定义网络则属于可眩
软件定义的核心理念就是“控制平面（Control Plane）”与“数据平面（Data Plane）”分离，说得通俗一点，就是软件与硬件的解耦，避免被专用硬件锁定，这也是为何超融合都使用商用x86硬件的原因之一。
控制平面与数据平面的分离，意味着底层基础设施需要将控制权上交，同时又需要具备更高级的智能（智能下沉）。控制权上交意味着更简单的管理，可以在单一界面调度、分配并监控整个服务器集群乃至整个数据中心的资源；智能下沉则意味着更高效的数据处理，数据平面在最接近数据的地方按（控制平面）需处理数据，能够让数据中心的资源利用率更高。
具体到VxRailDell EMC服务器与VMware软件紧密集成的超融合解决方案中，vCenter就相当于是服务器集群或数据中心级操作系统，负责统一调度和分配资源。但vCenter在对底层硬件平台的监控方面则相对较弱，通常只能显示CPU与内存的信息，除这二者，服务器中实际上还有硬盘、网卡乃至GPU等其他组件。
更简单高效运维，成长型企业需要这样的云计算新基建
（在E企研究院测试的VxRail E系列超融合中，某一节点在vCenter中的信息显示，只有CPU与内存信息，信息显示也相对简略）
要查看服务器内部的其他硬件详细信息需要进入服务器自身的管理界面（如iDRAC），在一个最少4节点，最多可达几十甚至几百个节点的服务器集群中，要快速定位特定的某个服务器节点，这可能并不是一件容易的事情。
在VxRail中，Dell EMC专门引入了一个名为“VxRail Manager”的虚机，这一虚机负责收集集群中所有VxRail节点及其内部组件的健康状态信息，并经过可视化后上呈给vCenter。
更简单高效运维，成长型企业需要这样的云计算新基建
（在E企研究院测试的VxRail E系列超融合中的VxRail Manager虚机，4 vCPU与16GB的内存配置，对于整个服务器集群而言，所占用的资源并不多）
尽管多了VxRail Manager虚机，但这个虚机更像是一个在后台运行的程序，用户并不需要登录这个虚机，也不需要登录专门的网页。因为VxRail Manager已经将处理过的信息都上呈给了vCenter。
更简单高效运维，成长型企业需要这样的云计算新基建
【在vCenter中，只需要选中相应的VxRail节点，点击“监控”菜单，然后在最底下的“VxRail”菜单中就可以看到这一节点的组件信息，上图中显示了电源的信息，右侧显示的是用于安装操作系统（ESXi）的BOSS卡信息】
各VxRail超融合节点的信息在经过VxRail Manager处理后，在vCenter中以一种类似“数字孪生”的方式呈现，所谓数字孪生就是数字世界与现实世界实现一一对应，在数字世界进行的操作会映射到现实世界中。
如上图中显示的VxRail E系列超融合节点图形中，每一个图形化的组件都是可点击的，通过点击可以查看相应组件的详细信息。而点击某一组件后，右侧上方会有“操作”菜单，里面相应的可操作选项，如下图：
更简单高效运维，成长型企业需要这样的云计算新基建
（如果没有选中任何组件，则默认选中整个节点，“操作”菜单中可进行关机等操作）
通过VxRail Manager，使得vCenter可以在单一管理界面实现节点内部组件级别的监控管理，同时又不过多占用vCenter的资源。如果用户仍习惯于传统的iDRAC管理方式，也可以通过点击上图中的iDRAC地址进入到节点的iDRAC管理界面中。
更简单高效运维，成长型企业需要这样的云计算新基建
（同时，VxRail Manager也提供集群视角的监控，选中服务器集群，进入监控菜单中，可以显示此集群中所有的节点信息，选中某个节点，通过右侧的操作菜单可进行相应的操作）
VCF on VxRail：深度集成 一键更新 安全管理
对于数据中心基础设施管理而言，状态监控只是重要任务之一，更重要的任务还有更新和升级，比如对服务器节点的BIOS更新、操作系统更新与升级等。
那么VxRail又是通过什么样的方法来帮助用户提升数据中心的管理效率的呢？
选中VxRail集群，然后进入“配置”页面，在最底层同样有名为“VxRail”菜单，在这个菜单之下有多个子选项，如“系统”、“更新”与“证书”等，“更新”就是我们所要找的功能。
更简单高效运维，成长型企业需要这样的云计算新基建
【在E企研究院测试的这套VxRail中，由于已经安装了VMware Cloud Foundation（简称VCF）软件，所以在“更新”页面中提示，VxRail系统由VCF管理。在页面中也显示了当前VxRail已经安装的组件和版本信息】
VCF是VMware基于超融合基础架构技术构建的混合云平台，通过这一云管理平台可以管理企业数据中心内的工作负载。具体到E企研究院测试的这套VxRail中，VCF安装在名为“SDDC”的这个虚机之中（SDDC应为Software Define Data Center之意，即软件定义的数据中心）。
更简单高效运维，成长型企业需要这样的云计算新基建
（E企研究院测试的这套VxRail中的，用于提供VCF服务的SDDC虚机，通过上图中的DNS名称或IP地址，通过浏览器可直接登录到VCF管理界面）
更简单高效运维，成长型企业需要这样的云计算新基建
（在VCF中显示了当前VxRail超融合集群中的工作负载与资源使用情况，对于当前工作负载的资源使用情况一目了然）
我们要找的更新功能就在左侧的“生命周期管理”菜单中，鼠标点击即可进入：
更简单高效运维，成长型企业需要这样的云计算新基建
（在生命周期管理的“包管理”页面中，显示了适用于当前VxRail超融合集群的更新包，通过点击就可以下载，不过需要VMware账户和Dell EMC支持账户）
更简单高效运维，成长型企业需要这样的云计算新基建
（在“管理”菜单的“存储库设置”中可以输入或更改VMware账户与Dell EMC支持账户）
通过上述操作可以看到，Dell EMC VxRail通过与VMware Cloud Foundation的深度集成，可以在VCF的单一管理界面中就实现整个VxRail集群的更新或升级。
“一键更新”也意味着所有超融合节点都处于相同的基线（如相同的BIOS版本、操作系统版本等），极大地避免了手动升级过程中的人为误操作风险，也大幅节省了数据中心运维管理所耗费的时间。
总结：硬件加速 软件智能定义
随着边缘数据也迎来了爆发性增长，工业、农业、能源、运输、安防等传统行业开始探索在靠近数据生产者的边缘提供数据处理的功能，解决大量异构设备和网络带来的复杂性问题，以及生产数据的实时性和可靠性问题。
VxRail 通过软件定义实现计算、存储和网络资源池化，这种资源的一致性管理，不仅加快 IT 部署，使部署时间大大缩短，并实现了一键升级，一站式服务释放架构管理资源，降低硬件、软件、 中间件升级对业务性能和安全性的影响，既可以部署在数据中心，也可以部署在边缘。
通过此次E企研究院验证后，我们总结出VxRail的架构特点：
E系列节点是Dell EMC VxRail中唯一采用1U工业标准设计的节点，其小巧的设计，哪怕是4节点部署，也最小化了空间占用。
E系列每个VxRail节点中只配备了一颗AMD EPYC 7502P处理器，但并不弱于主流的双路配置节点，在数据库应用等在线业务场景中，获得更高的性能，不管是支撑虚拟化场景，还是计算密集型场景均可支持。
VxRail E系列通过在每个微小处进行改良设计，来提升灵活性和可扩展性，比如配备了BOSS卡，用于安装操作系统，这样就可以将前面板上的10个硬盘仓都留给实际数据存储。
具备开箱即用、灵活弹性扩展以及完善的云计算服务能力，有助于企业节约IT成本、应对边缘计算等新型业务场景挑战，快速实现数字化转型。
VxRail不仅是基于超融合技术的完整数据中心生态，也是VMware云原生应用的基础架构，它完整地集成了戴尔易安信和VMware的生态，是紧耦合的超融合数据中心解决方案，具备完整的数据中心功能。通过此次实测，E企研究院认为：
Dell EMC VxRail超融合系统通过VxRail Manager以及与VCF的深度集成，在单一管理界面实现了集群乃至数据中心系统资源的监控和管理，大幅简化了用户运维数据中心的操作流程。
Dell EMC VxRail还实现了硬件平台、超融合平台、网络配置初始化管理和虚拟化平台的单一界面的统一管理。
其端到端全堆栈集成的生命周期自动化管理能力，可简化、精简和自动化SDDC的运营，更能一键式全堆栈自动化修补和升级SDDC平台，使得客户可以方便实现自动化、安全和方便的软件更新极大地提高了数据中心的管理效率。
Dell EMC VxRail 管理器与 VMware vCenter 管理深度整合，保证 VxRail 在连续的已认证各种工作负载持续稳定运营的条件下，实现不影响业务运营基础上的升级、扩展、退役节点，并保证企业级一致性架构、管理和服务。
这个方案可以用于构建企业级混合云、融合边缘到数据中心的应用，能够帮助企业用户更快、更高质量地完成新型数据中心建设，实现从私有云到混合云的无缝拓展，加快企业业务部署，更好地支撑企业的数字化建设。DevOps 原则和云原生应用程序开发流程的采用正在推动文化和技术变革，帮助企业变得更加灵活，加快市场开发速度。除了更快的开发，这些技术还提供了更好的用户体验、更灵活的管理、更高的可靠性和更低的成本。与使用云的应用程序相比，云原生应用程序是在云中构建和部署的。它们使用容器和微服务架构来提供更快的应用程序开发和交付，以及更大的灵活性。
IDC 预测，到 2022 年，90% 的新企业应用程序将使用云原生应用程序开发流程、敏捷方法论和 API 驱动架构。根据一份调查报告，全球有大约 650 万活跃的云原生开发者，约有 400 万开发者使用无服务器架构和云方法。现在 92% 的组织在生产环境中使用容器。
1
云原生架构引入新风险
虽然好处引人注目，但云原生架构也引入了各种新型安全风险和潜在的漏洞源。现有的应用程序安全性方法并不是针对新范式设计的。相反，DevOps 团队需要一种新的方法来帮助他们更好地识别潜在风险，并使它们能够将漏洞管理集成到开发和交付流程中。
早期，软件开发被认为是一个线性过程，但云原生架构的兴起导致了高度动态的应用程序环境。在这里，变化是唯一不变的。根据研究，61% 的组织认为他们的环境每分钟或者更短时间就改变一次。云原生、基于容器的环境的动态特性，以及跟上敏捷开发速度的需要，使得检测漏洞和管理应用程序安全更加困难。
根据一份调查报告，在 2020 年上半年期间，每天有 160 起针对蜜罐的攻击。其中 95% 的攻击旨在劫持资源，而 5% 的攻击旨在发起网络拒绝服务攻击。这个研究还表明，微服务、容器和 Kubernetes 为 89% 的 CISO 创建了应用程序安全盲点。
2
检测和管理漏洞的挑战
传统的安全实践根本不适合这种环境。事实上，云原生架构从根本上破坏了应用程序的安全性。传统的安全漏洞管理方法无法跟上这些动态环境，因为传统方法只能提供单一时刻的静态视图，这使得它们的效率越来越低，并且容易出现盲点。具体有如下几个原因。
1. 增量开发
云原生应用程序是使用不断更新并部署到环境中的连续代码流开发的。快速的软件开发周期允许微服务应用的每个组件都进行每日更新。这种增量开发为已知和未知的漏洞创建了一个大型的攻击面。安全团队可能会发现，在不降低发布周期的情况下保护这些部署是一项挑战。
2. 位置的无常性
传统应用程序总是有一个连接的服务器或虚拟机（VM），这使得应用程序始终保持相同的 IP 地址和位置。但是，云原生应用程序既没有如此持久的位置，也没有任何清晰的边界。
在传统应用程序中，多个软件功能或进程会运行在一台虚拟机上。而现在，每个进程或功能都被打包为一个单独的容器，从而使每个实体暴露在泄露的漏洞中。它需要在整个开发生命周期中得到保护。
3. 从持续运行到按需运行的转变
微服务的兴起见证了从持续运行应用程序到按需运行的快速转变。在这些环境中，根据使用情况，基础设施会开启和关闭来支持数字服务。
这些基础设施还允许每个组件独立地自动地调整。这虽然提高了应用程序的操作效率，但也使得用传统或手动方法来保护它们和管理漏洞变得几乎不可能。
4. 缺乏优先次序
保护应用程序安全的传统方法主要侧重于在代码漏洞被利用之前识别和缓解代码漏洞。例如，在将应用程序放到生产环境之前，安全策略可能需要修复所有关键漏洞，只有这样，你才能进行下一步。
但是，基于涉及的相对风险和数千个漏洞的严重性来评估云原生应用程序既耗时又困难。此外，在处理云原生供应链和基础设施中的漏洞激增时缺乏优先级，会减慢开发速度，也不会让 DevOps 团队降低整体风险。
5. 不全面的漏洞扫描
云原生应用程序中的漏洞扫描通常仅在预生产阶段进行。因此，错过生产阶段运行的内容会增加在云部署中运行有漏洞的库的风险。由于无法区分潜在漏洞和真实暴露，它们对每个可能的漏洞发出堆积如山的警报。由于假阳性的数量巨大，这增加了组织理解其暴露风险影响的难度。
6. 漏洞的唯一性
云原生系统包含大量公有云和私有云、应用程序架构和云服务。每种架构模式都可能有其不同的漏洞和安全需求。安全团队需要了解这些复杂的攻击面，并找到保护每种不同架构的解决方案。
3
云原生安全的最佳实践
当涉及云原生应用程序时，安全性不能是事后诸葛亮。安全性必须集成到持续集成和持续开发流程中，而不是依赖于固定的解决方案和方法。采用基于风险的方法至关重要，但这并不是完整的解决方案。
一个完整的解决方案将这与各种其它安全层结合在一起，这些安全层超越了检测和评估，而转向了补救或缓解。这些措施包括调整安全性、在功能和容器级别应用外围安全性、保护应用程序依赖、强制执行最小角色和权限，以及利用共享的安全责任。
基于风险的方法
这种集成的实用安全性的首批实现之一可以是采用基于风险的方法进行云原生开发。这使得 DevOps 团队能够检测、评估和修复工件管道中的漏洞，作为开发过程中的一个集成组件。它还允许你对容器部署后的行为进行持续监控。
基于风险的方法允许你确定优先级。这个方法对漏洞进行打分，以评估每个漏洞的危险程度。全面的基于风险的方法必须确保在允许代码投入生产环境之前对风险进行分析和缓解。因此，安全控制必须转移到开发管道中，重点应该放在工件管道上。这种变化可以最小化组织的运行时攻击面。
边界安全
云原生应用程序的系统分为多个可调用组件，这些组件接受来自不同来源的事件驱动触发器。这为攻击者提供了更多的目标选择和许多恶意活动的载体。防范此类攻击的一个重要实践是使用为云原生环境构建的 API 和应用程序安全工具。除此之外的一般方法是在功能级别加强外围安全。识别由异常源触发的功能，并监控事件触发器中的异常。
在容器化环境中，必须确保多层次的安全。这可以包括编排器控制面板、物理主机、容器和运行单元。Kubernetes 等编排器的最佳安全实践包括隔离节点、对 API 服务器使用第三方身份验证以及限制和监控容器间的流量。
分配最低权限
由于云原生资源之间存在大量且频繁的交互，因此为每个容器分配唯一的权限组的能力为增强安全性提供了极好的机会。因此，如果云原生框架中的任何元素被破坏，它将造成最小的损害，并防止权限扩大到其它组件。
保护应用程序依赖项
云原生应用程序代码通常包含具有依赖关系的包。为了保护应用程序的依赖性，你需要特定的自动化工具，包括一个全面的开源组件及其漏洞数据库。
你还需要能够在开发过程中触发应用程序安全活动的云原生编排工具。通过连续运行上述工具，可以防止在生产环境中运行的函数或容器中包含有漏洞的包。
4
云原生应用将何去何从？
随着云环境变得越来越动态，组织必须确保应用程序的最大覆盖率，来帮助避免盲点，实时监测漏洞，并获取信息以评估风险。从长远来看，需要一种新的安全方法。Palo Alto Networks 产品副总裁 John Morello 认为，这些新方法包括：
保护应用程序编程接口 (APIs)
探索新的云原生安全指标和文化
转向机器学习和开源软件
API 是连接微服务和容器的最常见的形式，而这正是黑客获取数据并将恶意软件引入系统的目标。不幸的是，API 本身是不安全的，并且会受到攻击，因为通过编程，它们很容易访问。因此，你需要一个好的安全模型和恰当的工具来保护这些微服务。
对于云原生架构的长期安全运行，Morello 强烈建议使用 DevOps 指标。因为从安全角度来看，最重要的指标不是环境中的漏洞数量，而是修补或修复这些漏洞所需要的时间。
检测和管理漏洞是一项复杂的劳动密集型任务。在一切都是代码的时代，安全自动化是一种强劲的趋势。它特别适用于检测错误配置和漏洞、升级组件、根据安全最佳实践自动进行代码评审，以及关闭受侵害的运行单元。在上一篇文章（可中心可边缘，云计算“罗马大路”需要什么样的超融合新基建？）中，介绍了Dell EMC VxRail E系列超融合的硬件平台，使用单路AMD EPYC 7502P处理器，尽管是单路处理器，但7502P处理器具有32核心，64线程，并有128MB的L3缓存，以及8通道DDR4-3200MHz内存（最多16条），性能并不输于主流双路服务器，甚至性能更好；同时这款处理器支持128条PCIe 4.0通道，使得其可扩展性也超过了主流的双路服务器。
更重要的是，Dell EMC通过其强大的设计能力，让AMD EPYC7502P处理器不仅能够充分发挥出强大的计算性能，同时也具有极其灵活的可扩展性。
对于企业用户而言，强大灵活扩展的硬件平台只是必备条件，更重要的是运维与管理能力。那么作为超融合市场的“王者”，VxRail是如何帮助用户实现简单高效管理的呢？
集群视角 全生命周期管理
超融合基础设施从诞生之初就被赋予了构建新型数据中心的使命，其最大的特点就是“软件定义”软件定义计算、软件定义存储以及软件定义网络，前两者属于必备，软件定义网络则属于可眩
软件定义的核心理念就是“控制平面（Control Plane）”与“数据平面（Data Plane）”分离，说得通俗一点，就是软件与硬件的解耦，避免被专用硬件锁定，这也是为何超融合都使用商用x86硬件的原因之一。
控制平面与数据平面的分离，意味着底层基础设施需要将控制权上交，同时又需要具备更高级的智能（智能下沉）。控制权上交意味着更简单的管理，可以在单一界面调度、分配并监控整个服务器集群乃至整个数据中心的资源；智能下沉则意味着更高效的数据处理，数据平面在最接近数据的地方按（控制平面）需处理数据，能够让数据中心的资源利用率更高。
具体到VxRailDell EMC服务器与VMware软件紧密集成的超融合解决方案中，vCenter就相当于是服务器集群或数据中心级操作系统，负责统一调度和分配资源。但vCenter在对底层硬件平台的监控方面则相对较弱，通常只能显示CPU与内存的信息，除这二者，服务器中实际上还有硬盘、网卡乃至GPU等其他组件。
更简单高效运维，成长型企业需要这样的云计算新基建
（在E企研究院测试的VxRail E系列超融合中，某一节点在vCenter中的信息显示，只有CPU与内存信息，信息显示也相对简略）
要查看服务器内部的其他硬件详细信息需要进入服务器自身的管理界面（如iDRAC），在一个最少4节点，最多可达几十甚至几百个节点的服务器集群中，要快速定位特定的某个服务器节点，这可能并不是一件容易的事情。
在VxRail中，Dell EMC专门引入了一个名为“VxRail Manager”的虚机，这一虚机负责收集集群中所有VxRail节点及其内部组件的健康状态信息，并经过可视化后上呈给vCenter。
更简单高效运维，成长型企业需要这样的云计算新基建
（在E企研究院测试的VxRail E系列超融合中的VxRail Manager虚机，4 vCPU与16GB的内存配置，对于整个服务器集群而言，所占用的资源并不多）
尽管多了VxRail Manager虚机，但这个虚机更像是一个在后台运行的程序，用户并不需要登录这个虚机，也不需要登录专门的网页。因为VxRail Manager已经将处理过的信息都上呈给了vCenter。
更简单高效运维，成长型企业需要这样的云计算新基建
【在vCenter中，只需要选中相应的VxRail节点，点击“监控”菜单，然后在最底下的“VxRail”菜单中就可以看到这一节点的组件信息，上图中显示了电源的信息，右侧显示的是用于安装操作系统（ESXi）的BOSS卡信息】
各VxRail超融合节点的信息在经过VxRail Manager处理后，在vCenter中以一种类似“数字孪生”的方式呈现，所谓数字孪生就是数字世界与现实世界实现一一对应，在数字世界进行的操作会映射到现实世界中。
如上图中显示的VxRail E系列超融合节点图形中，每一个图形化的组件都是可点击的，通过点击可以查看相应组件的详细信息。而点击某一组件后，右侧上方会有“操作”菜单，里面相应的可操作选项，如下图：
更简单高效运维，成长型企业需要这样的云计算新基建
（如果没有选中任何组件，则默认选中整个节点，“操作”菜单中可进行关机等操作）
通过VxRail Manager，使得vCenter可以在单一管理界面实现节点内部组件级别的监控管理，同时又不过多占用vCenter的资源。如果用户仍习惯于传统的iDRAC管理方式，也可以通过点击上图中的iDRAC地址进入到节点的iDRAC管理界面中。
更简单高效运维，成长型企业需要这样的云计算新基建
（同时，VxRail Manager也提供集群视角的监控，选中服务器集群，进入监控菜单中，可以显示此集群中所有的节点信息，选中某个节点，通过右侧的操作菜单可进行相应的操作）
VCF on VxRail：深度集成 一键更新 安全管理
对于数据中心基础设施管理而言，状态监控只是重要任务之一，更重要的任务还有更新和升级，比如对服务器节点的BIOS更新、操作系统更新与升级等。
那么VxRail又是通过什么样的方法来帮助用户提升数据中心的管理效率的呢？
选中VxRail集群，然后进入“配置”页面，在最底层同样有名为“VxRail”菜单，在这个菜单之下有多个子选项，如“系统”、“更新”与“证书”等，“更新”就是我们所要找的功能。
更简单高效运维，成长型企业需要这样的云计算新基建
【在E企研究院测试的这套VxRail中，由于已经安装了VMware Cloud Foundation（简称VCF）软件，所以在“更新”页面中提示，VxRail系统由VCF管理。在页面中也显示了当前VxRail已经安装的组件和版本信息】
VCF是VMware基于超融合基础架构技术构建的混合云平台，通过这一云管理平台可以管理企业数据中心内的工作负载。具体到E企研究院测试的这套VxRail中，VCF安装在名为“SDDC”的这个虚机之中（SDDC应为Software Define Data Center之意，即软件定义的数据中心）。
更简单高效运维，成长型企业需要这样的云计算新基建
（E企研究院测试的这套VxRail中的，用于提供VCF服务的SDDC虚机，通过上图中的DNS名称或IP地址，通过浏览器可直接登录到VCF管理界面）
更简单高效运维，成长型企业需要这样的云计算新基建
（在VCF中显示了当前VxRail超融合集群中的工作负载与资源使用情况，对于当前工作负载的资源使用情况一目了然）
我们要找的更新功能就在左侧的“生命周期管理”菜单中，鼠标点击即可进入：
更简单高效运维，成长型企业需要这样的云计算新基建
（在生命周期管理的“包管理”页面中，显示了适用于当前VxRail超融合集群的更新包，通过点击就可以下载，不过需要VMware账户和Dell EMC支持账户）
更简单高效运维，成长型企业需要这样的云计算新基建
（在“管理”菜单的“存储库设置”中可以输入或更改VMware账户与Dell EMC支持账户）
通过上述操作可以看到，Dell EMC VxRail通过与VMware Cloud Foundation的深度集成，可以在VCF的单一管理界面中就实现整个VxRail集群的更新或升级。
“一键更新”也意味着所有超融合节点都处于相同的基线（如相同的BIOS版本、操作系统版本等），极大地避免了手动升级过程中的人为误操作风险，也大幅节省了数据中心运维管理所耗费的时间。
总结：硬件加速 软件智能定义
随着边缘数据也迎来了爆发性增长，工业、农业、能源、运输、安防等传统行业开始探索在靠近数据生产者的边缘提供数据处理的功能，解决大量异构设备和网络带来的复杂性问题，以及生产数据的实时性和可靠性问题。
VxRail 通过软件定义实现计算、存储和网络资源池化，这种资源的一致性管理，不仅加快 IT 部署，使部署时间大大缩短，并实现了一键升级，一站式服务释放架构管理资源，降低硬件、软件、 中间件升级对业务性能和安全性的影响，既可以部署在数据中心，也可以部署在边缘。
通过此次E企研究院验证后，我们总结出VxRail的架构特点：
E系列节点是Dell EMC VxRail中唯一采用1U工业标准设计的节点，其小巧的设计，哪怕是4节点部署，也最小化了空间占用。
E系列每个VxRail节点中只配备了一颗AMD EPYC 7502P处理器，但并不弱于主流的双路配置节点，在数据库应用等在线业务场景中，获得更高的性能，不管是支撑虚拟化场景，还是计算密集型场景均可支持。
VxRail E系列通过在每个微小处进行改良设计，来提升灵活性和可扩展性，比如配备了BOSS卡，用于安装操作系统，这样就可以将前面板上的10个硬盘仓都留给实际数据存储。
具备开箱即用、灵活弹性扩展以及完善的云计算服务能力，有助于企业节约IT成本、应对边缘计算等新型业务场景挑战，快速实现数字化转型。
VxRail不仅是基于超融合技术的完整数据中心生态，也是VMware云原生应用的基础架构，它完整地集成了戴尔易安信和VMware的生态，是紧耦合的超融合数据中心解决方案，具备完整的数据中心功能。通过此次实测，E企研究院认为：
Dell EMC VxRail超融合系统通过VxRail Manager以及与VCF的深度集成，在单一管理界面实现了集群乃至数据中心系统资源的监控和管理，大幅简化了用户运维数据中心的操作流程。
Dell EMC VxRail还实现了硬件平台、超融合平台、网络配置初始化管理和虚拟化平台的单一界面的统一管理。
其端到端全堆栈集成的生命周期自动化管理能力，可简化、精简和自动化SDDC的运营，更能一键式全堆栈自动化修补和升级SDDC平台，使得客户可以方便实现自动化、安全和方便的软件更新极大地提高了数据中心的管理效率。
Dell EMC VxRail 管理器与 VMware vCenter 管理深度整合，保证 VxRail 在连续的已认证各种工作负载持续稳定运营的条件下，实现不影响业务运营基础上的升级、扩展、退役节点，并保证企业级一致性架构、管理和服务。
这个方案可以用于构建企业级混合云、融合边缘到数据中心的应用，能够帮助企业用户更快、更高质量地完成新型数据中心建设，实现从私有云到混合云的无缝拓展，加快企业业务部署，更好地支撑企业的数字化建设。DevOps 原则和云原生应用程序开发流程的采用正在推动文化和技术变革，帮助企业变得更加灵活，加快市场开发速度。除了更快的开发，这些技术还提供了更好的用户体验、更灵活的管理、更高的可靠性和更低的成本。与使用云的应用程序相比，云原生应用程序是在云中构建和部署的。它们使用容器和微服务架构来提供更快的应用程序开发和交付，以及更大的灵活性。
IDC 预测，到 2022 年，90% 的新企业应用程序将使用云原生应用程序开发流程、敏捷方法论和 API 驱动架构。根据一份调查报告，全球有大约 650 万活跃的云原生开发者，约有 400 万开发者使用无服务器架构和云方法。现在 92% 的组织在生产环境中使用容器。
1
云原生架构引入新风险
虽然好处引人注目，但云原生架构也引入了各种新型安全风险和潜在的漏洞源。现有的应用程序安全性方法并不是针对新范式设计的。相反，DevOps 团队需要一种新的方法来帮助他们更好地识别潜在风险，并使它们能够将漏洞管理集成到开发和交付流程中。
早期，软件开发被认为是一个线性过程，但云原生架构的兴起导致了高度动态的应用程序环境。在这里，变化是唯一不变的。根据研究，61% 的组织认为他们的环境每分钟或者更短时间就改变一次。云原生、基于容器的环境的动态特性，以及跟上敏捷开发速度的需要，使得检测漏洞和管理应用程序安全更加困难。
根据一份调查报告，在 2020 年上半年期间，每天有 160 起针对蜜罐的攻击。其中 95% 的攻击旨在劫持资源，而 5% 的攻击旨在发起网络拒绝服务攻击。这个研究还表明，微服务、容器和 Kubernetes 为 89% 的 CISO 创建了应用程序安全盲点。
2
检测和管理漏洞的挑战
传统的安全实践根本不适合这种环境。事实上，云原生架构从根本上破坏了应用程序的安全性。传统的安全漏洞管理方法无法跟上这些动态环境，因为传统方法只能提供单一时刻的静态视图，这使得它们的效率越来越低，并且容易出现盲点。具体有如下几个原因。
1. 增量开发
云原生应用程序是使用不断更新并部署到环境中的连续代码流开发的。快速的软件开发周期允许微服务应用的每个组件都进行每日更新。这种增量开发为已知和未知的漏洞创建了一个大型的攻击面。安全团队可能会发现，在不降低发布周期的情况下保护这些部署是一项挑战。
2. 位置的无常性
传统应用程序总是有一个连接的服务器或虚拟机（VM），这使得应用程序始终保持相同的 IP 地址和位置。但是，云原生应用程序既没有如此持久的位置，也没有任何清晰的边界。
在传统应用程序中，多个软件功能或进程会运行在一台虚拟机上。而现在，每个进程或功能都被打包为一个单独的容器，从而使每个实体暴露在泄露的漏洞中。它需要在整个开发生命周期中得到保护。
3. 从持续运行到按需运行的转变
微服务的兴起见证了从持续运行应用程序到按需运行的快速转变。在这些环境中，根据使用情况，基础设施会开启和关闭来支持数字服务。
这些基础设施还允许每个组件独立地自动地调整。这虽然提高了应用程序的操作效率，但也使得用传统或手动方法来保护它们和管理漏洞变得几乎不可能。
4. 缺乏优先次序
保护应用程序安全的传统方法主要侧重于在代码漏洞被利用之前识别和缓解代码漏洞。例如，在将应用程序放到生产环境之前，安全策略可能需要修复所有关键漏洞，只有这样，你才能进行下一步。
但是，基于涉及的相对风险和数千个漏洞的严重性来评估云原生应用程序既耗时又困难。此外，在处理云原生供应链和基础设施中的漏洞激增时缺乏优先级，会减慢开发速度，也不会让 DevOps 团队降低整体风险。
5. 不全面的漏洞扫描
云原生应用程序中的漏洞扫描通常仅在预生产阶段进行。因此，错过生产阶段运行的内容会增加在云部署中运行有漏洞的库的风险。由于无法区分潜在漏洞和真实暴露，它们对每个可能的漏洞发出堆积如山的警报。由于假阳性的数量巨大，这增加了组织理解其暴露风险影响的难度。
6. 漏洞的唯一性
云原生系统包含大量公有云和私有云、应用程序架构和云服务。每种架构模式都可能有其不同的漏洞和安全需求。安全团队需要了解这些复杂的攻击面，并找到保护每种不同架构的解决方案。
3
云原生安全的最佳实践
当涉及云原生应用程序时，安全性不能是事后诸葛亮。安全性必须集成到持续集成和持续开发流程中，而不是依赖于固定的解决方案和方法。采用基于风险的方法至关重要，但这并不是完整的解决方案。
一个完整的解决方案将这与各种其它安全层结合在一起，这些安全层超越了检测和评估，而转向了补救或缓解。这些措施包括调整安全性、在功能和容器级别应用外围安全性、保护应用程序依赖、强制执行最小角色和权限，以及利用共享的安全责任。
基于风险的方法
这种集成的实用安全性的首批实现之一可以是采用基于风险的方法进行云原生开发。这使得 DevOps 团队能够检测、评估和修复工件管道中的漏洞，作为开发过程中的一个集成组件。它还允许你对容器部署后的行为进行持续监控。
基于风险的方法允许你确定优先级。这个方法对漏洞进行打分，以评估每个漏洞的危险程度。全面的基于风险的方法必须确保在允许代码投入生产环境之前对风险进行分析和缓解。因此，安全控制必须转移到开发管道中，重点应该放在工件管道上。这种变化可以最小化组织的运行时攻击面。
边界安全
云原生应用程序的系统分为多个可调用组件，这些组件接受来自不同来源的事件驱动触发器。这为攻击者提供了更多的目标选择和许多恶意活动的载体。防范此类攻击的一个重要实践是使用为云原生环境构建的 API 和应用程序安全工具。除此之外的一般方法是在功能级别加强外围安全。识别由异常源触发的功能，并监控事件触发器中的异常。
在容器化环境中，必须确保多层次的安全。这可以包括编排器控制面板、物理主机、容器和运行单元。Kubernetes 等编排器的最佳安全实践包括隔离节点、对 API 服务器使用第三方身份验证以及限制和监控容器间的流量。
分配最低权限
由于云原生资源之间存在大量且频繁的交互，因此为每个容器分配唯一的权限组的能力为增强安全性提供了极好的机会。因此，如果云原生框架中的任何元素被破坏，它将造成最小的损害，并防止权限扩大到其它组件。
保护应用程序依赖项
云原生应用程序代码通常包含具有依赖关系的包。为了保护应用程序的依赖性，你需要特定的自动化工具，包括一个全面的开源组件及其漏洞数据库。
你还需要能够在开发过程中触发应用程序安全活动的云原生编排工具。通过连续运行上述工具，可以防止在生产环境中运行的函数或容器中包含有漏洞的包。
4
云原生应用将何去何从？
随着云环境变得越来越动态，组织必须确保应用程序的最大覆盖率，来帮助避免盲点，实时监测漏洞，并获取信息以评估风险。从长远来看，需要一种新的安全方法。Palo Alto Networks 产品副总裁 John Morello 认为，这些新方法包括：
保护应用程序编程接口 (APIs)
探索新的云原生安全指标和文化
转向机器学习和开源软件
API 是连接微服务和容器的最常见的形式，而这正是黑客获取数据并将恶意软件引入系统的目标。不幸的是，API 本身是不安全的，并且会受到攻击，因为通过编程，它们很容易访问。因此，你需要一个好的安全模型和恰当的工具来保护这些微服务。
对于云原生架构的长期安全运行，Morello 强烈建议使用 DevOps 指标。因为从安全角度来看，最重要的指标不是环境中的漏洞数量，而是修补或修复这些漏洞所需要的时间。
检测和管理漏洞是一项复杂的劳动密集型任务。在一切都是代码的时代，安全自动化是一种强劲的趋势。它特别适用于检测错误配置和漏洞、升级组件、根据安全最佳实践自动进行代码评审，以及关闭受侵害的运行单元。