zoukankan      html  css  js  c++  java
  • Windows Server基础架构云参考架构:硬件之上的设计

    作者 王枫 发布于2014年1月27日

    综述

    毫无疑问,移动互联网、社交网络、大数据和云计算已经成为IT发展的四个大的趋势。其中云计算又为前三个提供了一个理想的平台。今天不仅互联网公司,很多传统行业的大中型企业也在建设自己的私有云。本文旨在介绍一个基于Windows Server 2012和System Center 2012 SP1构建基础架构云其硬件部分的参考架构。

    设计目标

    • 从运维角度,整个架构应该易于扩展,从小到4个机柜至大到整个数据中心可以方便的进行扩展和容量规划。
    • 从用户的角度,整个架构应该可以兼容不同的应用类型,比如对计算敏感型,大内存型,和IO密集型等不同类型。
    • 从服务交付的角度,整个架构应该能够满足不同的服务等级需求,如需要高可用的和无需高可用的。
    • 从经济型角度,整个架构应该不依赖特定的硬件厂商或产品。

    Windows Server基础架构云的参考架构

    Windows Server基础架构云的参考架构如下:

    图1 Windows Server基础架构云的参考架构

    本文中我们将集中讨论上面参考架构中的硬件设计部分。

    为了实现前面拟定的设计目标,我们采用的模型首先要保证在计算和存储之间实现松耦合,只有这样才能保证我们更灵活地调度计算、存储、网络三种基础资源,组建足够体量的资源池按需承载不同类型的应用。基于相同的目的,我们采用了集中的存储而不是使用更低成本的直连存储。虽然直连存储的成本更低,但我们所采用的存储方案具有更高的可靠性,弹性和灵活性,这些都是企业非常关注的。另外,我们没有采用传统的光纤存储而代以新的完全基于网络的文件共享存储,这样的好处是相对于光纤存储,硬件采购成本较低,而且降低系统复杂度以及维护成本,但这样设计要求网络的部分必须具备足够的可靠性和高性能来满足IO密集型的需求。

    图2 Windows Server基础架构云的硬件架构模型

    标准IaaS SKU

    企业内部系统传统上主要通过冗余来实现高可用,例如对于一台服务器,所有的组件能冗余的都要冗余(比如内存、硬盘、网卡、电源),有的系统甚至实现了主板、CPU的冗余,但这样一来就意味着要投入昂贵的硬件。与此不同的是,市场上主流的公有云服务商为了给大部分客户提供低成本的服务,将高可用的责任很多时候交给用户来处理,比如要求用户的应用需要具备弹性能力(resilience),将相同角色的多个实例部署在不同的Fault Domain/Update Domain中来提高整个服务的高可用性。在本设计中我们借鉴了公有云的这一经验,不要求采用如此高度冗余的设备,相反我们的故障单元是机柜而不是里面某台服务器或存储,也就是说我们关注的是跨机柜的可靠性,包括了基础架构、平台、应用和数据。但同时考虑到对于私有云,更多的时候面临的是将企业现有的应用迁移到云上,这些应用很可能不能很好的处理stick session等问题,很难通过横向扩展多个无状态的实例来实现高可用,故而私有云IaaS在设计时还是应该考虑到为传统应用,甚至为传统上很难实现高可用的应用提供基础架构层级的高可用性服务。在这个设计中对于没有高可用性需求的用户,也可以在下面的设计中增加非群集的Hyper-V服务器和存储服务器来提供不同服务等级的服务。

    图3 标准IaaS SKU的构成

    计算节点的设计

    对于计算节点我们设计了两组网络,所有的虚拟机发生的网络访问流量都走租户网络上的虚拟网络,而虚拟机发生的存储访问流量都重定向到物理机操作系统通过数据中心网络使用具备SMB Direct的SMB3协议直接同文件服务器群集通讯。

    图4 计算节点的实现

    租户网络和数据中心网络在计算节点的用途小结如下:

    租户网络用于:

    • 租户到租户的通讯
    • 租户到外部的通讯

    数据中心网络用于:

    • 到存储节点的通讯(也就是到文件服务器,使用RDMA网卡)
    • 虚拟机的实时迁移
    • 虚拟机存储的实时迁移
    • 群集心跳线

    下面是一个标准的计算节点的硬件配置:

    项目

    标准配置

    处理器

    Intel Sandy Bridge CPU, 2 Socket x 6 cores (ES2640, Core frequency 2.5 GHz) = 12 cores

    内存

    16 DIMM x 8 GB = 128 GB

    存储

    内置 200 GB SSD (eMLC)

    网络

    2 x 10 GbE onboard (虚拟机所用的网络)

    2 x 10 GbE mezzanine with RDMA (用于访问存储节点、管理和实时迁移)

     表1 计算节点的标准配置

    存储节点的设计

    本设计中采用的存储架构是基于Windows Sever 2012的故障转移群集。以两节点来实现连续高可用(Continuous Availability)。为了提高性能,减少对于主机CPU的压力,采用了RDMA网卡,借助Windows Server 2012的SMB3文件服务器为计算节点提供Hyper-V虚拟机的存储。

    图5 存储节点的实现

    存储节点通过SAS HBA卡连接了共享的SAS接口硬盘柜,每个节点到磁盘柜额带宽高达48Gb/s (2x4x6Gb/s)。

    这里的数据中心网络用于:

    • 到计算节点的通讯
    • Storage Space重定向流量
    • 备份和复制流量

    下面是一个标准的计算节点的硬件配置:

    项目

    标准配置

    处理器

    Intel Sandy Bridge CPU, 2 Socket x 6 cores (Core frequency 2.5 GHz) = 12 cores

    内存

    16 x 8 GB = 128 GB

    存储

    2 x 10 GbE mezzanine with RDMA

    网络

    132 x 2.5” 10K SAS 900 GB Drives

    2 x JB9

    表2 存储节点的标准配置

    下图展示了计算节点和存储节点的连接方式

    图6 计算节点和存储节点的连接

    网络的冗余设计

    本设计中使用的网络三层都有冗余,他们分别是:

    • 每个数据中心2个汇聚层交换机
    • 每个机柜2个租户网络交换机
    • 每个机柜2个数据中心网络交换机

    网络Trunk设置:

    • 4 x 10 GbE租户网络接口聚合
    • 4 x 10 GbE 数据中心网络接口聚合 -> Aggregate
    • 16 x 10 GbE 聚合到核心交换

    下面是示意图:

    图7 网络的冗余设计

    小结

    企业在设计自己的基础架构云时可以考虑采用或者部分采用上面的设计,事实上微软自己的很多产品已经采用了上面的设计,比如微软SQL Server 2012的并行数据仓库(PDW)就采用了类似的架构。微软自己的模块化数据中心也是采用一样的架构。

    由于篇幅所限,我们讨论硬件之上的设计,正如我们一开始所说的,我们的目标之一就是用应用的弹性取代对于硬件冗余的需求,当我们把一个机柜最为一个故障单元的时候,如何跨机柜、甚至跨数据中心来调度、部署应用就显得非常重要。这个部分我们将在以后进行介绍。

    感谢马国耀对本文的审校。

    本文转载自:http://www.infoq.com/cn/articles/windows-server-infrastructure-cloud-reference-architecture

  • 相关阅读:
    The Quad
    将OrCAD Capture CIS的设计文件(.dsn)导入到PADS Logic VX.2.3
    OrCAD Capture CIS 16.6 将版本16.6的设计文件另存为版本16.2的设计文件
    Eclipse IDE 添加jar包到Java工程中
    PADS Logic VX.2.3 修改软件界面语言
    切换Allegro PCB Editor
    Allegro PCB Design GXL (legacy) 将brd文件另存为低版本文件
    Allegro PCB Design GXL (legacy) 设置自动保存brd文件
    Could not create an acl object: Role '16'
    windows 下apache开启FastCGI
  • 原文地址:https://www.cnblogs.com/new0801/p/6176196.html
Copyright © 2011-2022 走看看