NetApp Tech OnTap
     

第三代 NetApp Kilo 客户端

自 2006 年以来,Tech OnTap 逐年记录着 NetApp Kilo 客户端这一 NetApp 大型工程测试环境的演变历程。在本文中,Tech OnTap 专门邀请 NetApp RTP 工程支持系统团队的 Brad Flanary 来说明根据计划将要完成的下一代创新型重要测试环境的目标和技术。[Tech OnTap 编者按。]

借助 NetApp® Kilo 客户端这样出色的测试环境,NetApp 能够迅速地配置和启动大量的物理和/或虚拟客户端,测试 NetApp 存储硬件和软件。我们于 2005 年部署了第一代 Kilo 客户端(在一篇早期的 TOT 文章中有过讲述)。最初的第一代 Kilo 客户端能够提供 1,120 个物理客户端,这些客户端从 iSCSI 而不是本地硬盘启动。

到 2007 年中,Kilo 客户端规模已经发展到拥有能从 iSCSI、FC 或 NFS 启动的 1,700 个物理客户端,并能部署为运行 Windows® 或 Linux® 或运行在虚拟化 VMware® 环境中的物理客户端。在当时发表的一篇 Tech OnTap 文章中,重点介绍了我们使用 NetApp FlexClone® 和其他 NetApp 技术迅速提供物理服务器和虚拟环境的技术。

该配置极好地帮助了 NetApp(自上篇文章发表后又添加了几台服务器,以支持负担沉重的虚拟化),但是大约三年过去后,随着原来租赁的服务器设备即将到期,现在需要再一次升级配置,才能应用最新的技术和云计算发展成果。

本文将重点介绍第三代 Kilo 客户端设计,该客户端建成后,您能够:

  • 同时使用最多 7 万 5 千台虚拟客户端进行测试(远远超出 Kilo “千台”客户端的含义)。
  • 对更广泛的网络配置进行测试,其中包括万兆以太网和光纤通道以太网 (FCoE)。
  • 在几小时内部署完上百或上千客户端。

本文将从我们面对的全新需求开始阐述,然后谈论硬件升级的问题,并对将于本年上半年度推出的第三代 Kilo 客户端设计加以说明。我们还将讨论 kilo 客户端所在的 NetApp 数据中心设施的独特设计。

收集需求信息

我们与内部客户进行交流,并考虑到了当前配置所无法满足的要求,逐渐形成了下一代 kilo 客户端要达到的要求的想法。不过,为了保证我们想法的准确,我们已经对我们现有的内部客户和 NetApp 中其他潜在的 kilo 客户端用户展开了新的详细问卷调查。您可以单击图 1 打开并通览文档,查看我们调查的内容。(您会注意到针对虚拟化而提出的一些问题,因为我们特别想要了解虚拟客户端是否比物理客户端更能满足客户的需求。)



图 1)Kilo 客户端调查与结果。

主要调查成果如下:

  • 虚拟硬件比物理硬件能更好地服务我们大多数的客户。
  • 万兆以太网需求量极高。
  • 在不久的将来会对 FCoE 有较高的需求(该调查在几月前完成,FCoE 需求现在已经显示出来)。

该调查极富价值。它证明了我们对虚拟硬件能比物理硬件更好地服务我们大多数客户的设想。很明显,这与 IT 业中当前持续增长的虚拟化和云计算趋势相吻合。也与最近 NetApp 中更多服务器虚拟化的趋势相吻合。(2009 年 4 月发表的一篇 Tech OnTap 文章讲述了印度班加罗尔 (Bangalore) NetApp 工程实验室中从物理迁移到虚拟的
案例。



评估硬件

了解了我们对新 Kilo 客户端的要求后,我们的下一步就是开始评估服务器硬件。我们向许多服务器供应商发送了 RFP 以获得产品进行评估。我们的测试重点放在以下几个方面:

  • 能够支持聚合网络适配器 (CNA)(该适配器既能支持 FCoE 又能支持 10GbE),请参阅这篇最近发表的 Tech OnTap 文章获得有关 CNA 的更多信息)
  • 支持虚拟化
  • 性能
  • 能否按照需要扩展或缩减

我们从三个方面对全部服务器进行了测试:使用 CNA 能提供怎样的性能、对虚拟机的大规模支持效果、对标准基准电池的使用情况。

我们迅速发现,基于 Intel® Nehalem 微架构处理器的服务器的性能明显超出旧 Intel Core™ 微架构处理器 (Dunnington) 的性能,能更好地满足我们的需求。我们选用的这两种服务器模式均使用了 Nehalem 处理器。

在网络方面,我们最近在我们的新全球动态实验室 (GDL) 中部署了 Cisco Nexus 基础架构。我们将继续使用该网络架构以满足 kilo 客户端的 FCoE 和 IP 需求。我们还将为光纤通道使用 Brocade 转换。

第三代 Kilo 客户端部署计划

服务器:

  • 468 Fujitsu RX200 S5、48GB、2CPU:2.26 GHZ Intel Xeon E5520 处理器 (Nehalem);(这些是 4 核 8 线程处理器,能够在每个系统上提供 8 核和 16 线程)
  • 160 Cisco UCS 服务器(与 Fujitsu 处理器配置相同):
    • 48 个 48GB 内存服务器
    • 112 个 24GB 内存服务器

该配置计划总共可以使用 5,024 个内核,提供 628 个客户端。它们可以取代原 Kilo 客户端的三个舱或使用 1,456 个内核提供的 728 个物理客户端。这些客户端全部可以优先作为虚拟服务器运行,也可以部署为物理客户端。因为每台物理服务器上能够安装 120 个 VM,我们将能够从 kilo 客户端提供最多 75,360 个 VM。

前一代 kilo 客户端上剩余的大约 1,000 客户端将保留不动,留作测试之用。随着租赁到期,我们将逐步停用并退回这些客户端。

网络:

  • 核心:Nexus 7018(16 个 I/O 模块、Backplane 可扩展到 15Tbps)
  • 聚合:Nexus 5010 和 5020
  • 访问:Nexus 2148T (FEX)
  • 光纤通道:Brocade DCX 控制器和 5320 边缘交换机

存储:

  • FC 启动:4 NetApp FAS 3170 存储系统
  • NFS 启动:16 NetApp FAS 3170 存储系统
  • 其他存储:选择了全部最新的 NetApp 存储、平台和磁盘

我们通常在每 NFS 数据库中启动 500 个 VM。根据需要,我们使用 SnapMirror® 从中央库向每个启动存储系统复制黄金映像。

启动物理硬件和虚拟机

Kilo 客户端真正的关键功能是能够以迅速、灵活且节省空间的方式执行启动。在任何云基础架构中,我们都必须能够为任何任务(无论是物理还是虚拟任务)重新定位客户端数量的目标。Kilo 客户端综合使用 FC 和 FCoE 启动以启动每个物理服务器,并使用 NFS 启动为在服务器上配置为运行虚拟化的虚拟机启动提供支持。

我们选择 FC 启动进行物理启动是因为在现有 Kilo 客户端基础架构中已经证明了 FC 启动的可靠性。在多数大型服务器安装中,物理服务器每次都启动同一启动映像。这可能是在物理环境中启动 Linux 或 Windows,或是在虚拟环境中启动 VMware ESX,但启动的方式始终一样。但 Kilo 客户端不是这样。我们的某个服务器可能第一天启动 Linux,第二天启动 VMware,第三天启动 Windows。结合我们的动态 LUN 克隆功能,我们能使用 FC 启动迅速高效地启动我们的物理和虚拟服务器。

在之前的文章中提过,我们为我们使用的每个操作系统和应用程序堆栈维护了一套"黄金"启动映像(例如光纤通道、LUN)。通过 NetApp SnapMirror® 和 FlexClone,我们可以迅速地对正在配置用作测试的每个物理服务器克隆上百份副本。仅需要向每个已配置服务器的核心映像添加一个主机专用的"自定义"即可。通过这一独特的方法,我们可以提供几乎瞬时的映像配置,而占用的空间几乎为零。

启动虚拟机的流程包括以下几步:

  • 在每台测试主机上启动 VMware ESX。
  • 在 VMware Virtual Center (vCenter™) 上动态注册这些主机。
  • 为虚拟机准备正确的网络设置和数据存储。
  • 使用 NetApp Rapid Cloning Utility (RCU) 复制虚拟机相应的编号和类型。RCU 将在 vCenter 中自动注册 VM。
  • 在 DNS 和 DHCP 中动态注册这些服务器,并启动虚拟机。
  • 检查,确保每项操作无误。

完全自动化。在过去几年间,我们创建了 Perl 脚本,如果配合 NetApp 和 VMware 工具使用,能够自动化上述步骤,因此,我们可以在 2 到 3 小时内简单地部署完 500 到 1,000 台虚拟机。(其中包括了物理启动过程和 VM 启动过程耗费的时间。这与其他的一些部署不同,在部署仍基于运行的 VMware 时发表的 Tech OnTap 文章里对这些其他部署有所阐述。)

最大空间效率。该过程的另一独特特点是所需要的存储空间极低,这是因为我们使用 FlexClone 克隆的是“黄金映像”而不是副本。我们只需要使用大约 500GB 存储空间(每客户端 1GB)就能简单地部署 500 台虚拟机,必要时使用的空间甚至可以更少。

通过新的基础架构,我们最多能配置 7 万 5 千台虚拟机进行超大型测试。全部新硬件到位后,我们能够报告尽快完成的时间。我们应该注意到,组成 Kilo 客户端的客户端划分为多个更小的部分,并行进行测试。

物理布局。前一代 Kilo 客户端的基础是“舱”,服务器、网络和启动存储均存放其中。如果设计要求的硬件规格极为接近、需要手动设置和拆卸,那么该方法会很有用。

我们为新 Kilo 客户端重新考虑和设计了舱方法。新设计方法将注意力集中于一个位置中的全部启动基础架构。现在,服务器和存储系统将组成到舱中,而舱中仅包括必须的交换(IP 和 FC)以满足舱的要求。这样,将更容易复制舱,也更易于将 Kilo 客户端增加和扩展到任意大小,只要添加另一该类型的舱即可。(换句话说,我们可以添加一舱服务器或一舱存储等)。因为不再需要或必须进行手动设置和装卸,在需要更多空间时,新舱可以而且也将部署在数据中心的任意位置,因此数据中心本身的运营将达到最高效率。

我们的全球动态实验室

Kilo 客户端的实际位置位于 NetApp 的全球动态实验室,这是位于北卡罗来纳州 Research Triangle Park 的 NetApp 工厂中的创新型新数据中心。Kilo 客户端将成为 NetApp 工程共享测试倡议(Shared Test Initiative,即 STI)的组成部分,该倡议将提供多个测试平台,重点关注部署、测试和结果收集的自动化。STI 将帮助连接这些资源,这样我们能够动态共享我们实验室中的全部资源。

设计 GDL 时,我们始终都在考虑效率和自动化。它包括 36 个空调房,每间房中大约有 60 套机柜,总共 2,136 套机架。

GDL 等现代数据中心的关键设计元素包括:

  • 您能够为每套机架提供多少电能?现在,由于占用空间更少,硬件消耗的电能更多
  • 要提供充足的冷却,您能够为每套机架提供多少空间?
  • 您利用电能的效率有多高?当前电能使用效率的标准是电能利用率 (PUE) 2.0

对于 GDL,需要根据每机架平均 12 kW 的标准布置电源和冷却,每空调房总共需要 720 kW。每机架分配的电源是 42 kW。通过我们专有的电压控制技术,我们能够在一个机柜中使用最高 42 kW 进行冷却,或是只要空调房总冷却负载不超过 720 kW 即可完成任何组合负载配置。

GDL 使用以下综合技术运行,以求达到最高电源效率:

  • 只要可能,就使用室外空气进行冷却
  • 电压控制冷却,限制风扇和排气泵耗用的电能
  • 提高空气温度(70 到 80 华氏度,而通常温度只有 50 到 60 华氏度)以及冷却水温度
  • 办公室余热再利用等

通过这些和其他技术,GDL 能够实现的年度 PUE 估计可以达到大约 1.2。也就是说,与运营 PUE 2.0 相比,GDL 每年的运营节省将超过的 7 百万美元,并能减少排放 9 万 3 千吨二氧化碳。您可以在最近的白皮书中了解更多有关 NetApp 实现数据中心效率方法的信息。

结论

下一代 NetApp Kilo 客户端将充分实现最新服务器硬件、网络技术和 NetApp 存储硬件和软件的优势,
为需要大量虚拟或物理客户端的测试创建灵活、自动的测试平台。完成后,Kilo 客户端将能够提供 7 万 5 千多虚拟客户端,并能利用千兆以太网、万兆以太网、光纤通道或 FCoE 的优势(全部都采用端到端的方式)。

随着将来下一代 Kilo 客户端对现有版本功能的极大提高,它最终将减少物理服务器的数量。

 对 NetApp Kilo 客户端有何见解?

请在 NetApp 社区中在线提出问题,交流观点,分享想法。

Brad Flanary
工程应用系统经理
NetApp

Brad 于 2006 年加入 NetApp。他现在领导着一个有着六名工程师的团队,负责 NetApp 动态数据中心、RTP 工程数据中心以及 NetApp 的全球工程实验室网络。加入 NetApp 前,Brad 在 Cisco Systems 担任了 7 年 LAN 交换专家的职位。他在大范围 LAN 和数据中心领域总共有 13 年以上的经验。

Kilo 客户端团队
NetApp

工程支持系统团队由 Brandon Agee、John Haas、Aaron Carter、Greg Cox、Eric Johnston 和 Jonathan Davis 组成。

了解