NetApp Tech OnTap NetApp Logo
NetApp Tech OnTap
     
案例研究: Be The Match

数以千计患有危及生命的疾病(例如白血病、淋巴瘤或镰状细胞病)的患者需要进行骨髓移植,但在自己的家族中却找不到合适的配型。超过 70% 的患者依靠 Be The Match® 寻找配型。Be The Match 由非营利组织美国国家骨髓捐献计划® (NMDP) 运营,旨在帮助患者与供者建立联系。在过去的 25 年中,我们根据 HLA 类型确定合适的配型,协助为患者实施了超过 5 万次移植。HLA 配型指标提供的配型比仅凭血型进行配型更为精准。

患者的医生可以与我们联系,在我们的 Be The Match Registry® 中进行搜索,从全球超过 1500 万会员和 40 万份脐带血中寻找配型。我们采用的复杂算法能够快速确定最接近患者的配型。只需几分钟,我们就能确定潜在的供者。掌握该信息之后,我们便能着手联系相关人员,并请其接受进一步的医学筛选,以便为患者寻找最合适的供者。最后,选定最佳供者并安排他们在采血中心进行捐赠。志愿者会将采集的骨髓或外周血干细胞 (PBSC) 送到患者已做好准备接受移植的医院。

您能想象得出,我们以电子形式存储和传输的数据越多、数据流动越快,选出合适的配型就越快、帮助的患者也就越多。从 2007 年开始,我们开始反思技术在 Be The Match 所起的作用。我们的目标是,到 2015 年,将每年促成的移植数量翻倍,同时将完成移植所需的时间从 96 天缩短到 45 天。

与其他许多快速发展的小型组织一样,Be The Match 也面临很多问题 — 自行研发的多个系统互不关联、数据来源众多并且数据池分散孤立。手动过程导致复杂性提升、效率降低,妨碍我们实现目标。在本文中,我将介绍我们如何以存储为出发点,逐步转变我们的 IT 基础架构,实现进一步发展所需的可用性、可扩展性、安全性和工作效率。此外,我还会介绍私有云和公共云计划。

尽管我们的 IT 转型任重而道远,但是目前取得的成果已经令我们振奋不已:

  • 我们已经将供者/患者配型到实际移植的时间从 96 天缩短了 15%。
  • 我们每年促成的移植数量持续增长,2010 年达到了 5500 例(2009 年为 4800 例)。
  • 我们能更快地整合结果数据,加快了我们专有患者/供者配型算法的演变。准确性越高,存活率也就越高。
  • 我们部署了面向公众的供者招募门户网站,注册会员每年增长 136%:新注册会员从平均每年 36 万(2000 到 2008 年)上升到平均每年 85 万(2009 和 2010 年)。

我们能取得这些里程碑式的成就,主要得益于 IT 方面的改进,正因如此,我们才得以提高可用性和效率。借助 NetApp® 存储,我们增加了部署的总存储(未增加管理人数),并通过精简配置和重复数据删除,降低了大约 35% 的总存储要求,节省了可观的资本和运营支出。

共享 IT 基础架构

2007 年我们开始转型时,我们的 IT 基础架构总共配备了约 90 台服务器,每台服务器都配有直连存储和磁带,而且没有实现服务器虚拟化。我们没有时间进行类似固件升级这样的日常维护,备份和灾难恢复 (DR) 也很困难,而且还遇到了几次非常严重的中断。这些问题迫使我们寻求一种具有集中存储的共享基础架构,帮助提高磁盘性能、降低管理成本并简化备份和灾难恢复。

目前,我们借助 NetApp 统一存储实现了标准化。2007 年,我们安装了两个 FAS3020 集群,在主数据中心和二级设施之间进行 SnapMirror ® 复制。那时,数据爆炸性增长才真正开始,我们在 2008 年执行了机头交换数据原位升级,升级两个集群,全部改用 FAS3040 控制器。就在当年,我们进一步将其中一个集群升级为 FAS3270 配置,以满足繁忙的开发和测试环境不断增长的需求。随着业务增长,我们能轻松升级中央存储,不断提高处理能力,而无需进行任何复杂的数据迁移,这种能力对我们来说非常重要。

2010 年,我们添置了一个 FAS6080 集群,专门用来支持我们的高端数据库。我们还配备了一个 FAS2040,用来支持我们的备份环境,因此目前我们共有四个 NetApp 阵列用于生产环境。

对于服务器环境,我们选择的是运行 Linux® 和 Windows® 的 IBM xSeries 服务器。目前我们全部应用程序中已有 50% 完成了虚拟化,只有某些传统的应用程序仍在 Solaris 环境中运行。我们还在不断向更高程度的虚拟化转型进军。在业务转型过程中,我们将应用程序从 Solaris 迁移到 Linux,以便它们能在 VMware® 环境中运行;我们也可能会部署一些打包应用程序来执行同样的功能。如果看一下我们运行的应用程序组合,会发现其中只有 10% 对我们的企业有很高的战略价值,其他的 90% 都应该能由现成的解决方案提供。像我们这样规模的公司(总共 780 名员工)绝不该再花费有限的精力去开发可由标准软件提供的非核心功能。

national marrow donor program storage architecture diagram

图 1) Be The Match 存储构架。

我们的主要应用程序(内部应用程序和现成应用程序)包括:

  • Traxis:移植中心使用此应用程序在资料库中查找配型
  • STAR LINK®:用于管理供者资料库的数据库
  • Oracle® E-Business Suite:最近部署的应用程序,用于处理财务及其他与业务相关的职能
  • Microsoft® Exchange:重要的协作程序,有助于不同地点之间的协调

利用 IT 实现远大的业务目标

上一部分介绍的共享 IT 基础架构给我们提供了许多必要的工具,帮助我们提高了性能、可用性和安全性,并改善了数据保护和灾难恢复,有助于我们实现远大的业务目标。NetApp 存储是支持我们在很多前沿领域不断进步的基础。

统一存储

Be The Match 是一个小型非营利性组织,因此没有足够的财力配备专用的存储系统来分别运行光纤通道、NFS 等。我们的生产环境中最初只有一个 NetApp 存储集群,因此我们在这一个集群上运行全部四个存储协议 — FC、NFS、CIFS 和 iSCSI。我们立即减少了九个 Windows 文件服务器,并将所有 CIFS 数据迁移到了 NetApp 存储。在上文提到的应用程序中,Traxis 应用程序使用 NFS,而 STAR LINK 是采用 Microsoft SQL Server® 后端的网络应用程序,因此它使用光纤通道。当然,Microsoft Exchange 也使用光纤通道,而 Oracle E-Business Suite 使用 NFS。少数几个数据集较小的应用程序使用 iSCSI。我们决定将去年添置的 FAS6080 专用于支持较大的数据库,因此它将只能使用 NFS 和 FC,但是我们其他的所有系统仍将支持四个协议,不会出现任何冲突和其他问题。

由于这些存储系统形成了集群,因此可提供极高的可用性(即使不具有我稍后要介绍的灾难恢复能力)。我在前面提到过,我们的存储控制器能够进行原位升级,无需迁移数据,这样我们便能满足不断增长的性能需求,而不会造成任何中断,也不必提前购买目前不需要的性能容量。

备份和恢复

在世界上的同类资料库中,Be The Match Registry 中存储的资料容量最大、供者的种族最多元化。在使用 NetApp 存储之前,备份 STAR LINK 数据库(用于存储这些资料)需要 24 小时才能完成,因此当天的备份会持续到第二天,并且会与第二天的备份发生冲突。通过采用 NetApp SnapManager® for Microsoft SQL Server (SMSQL),我们将总备份时间缩减为不到 4 小时,并且不会中断数据库访问。

除了 SMSQL,我们还使用 SnapManager for Exchange (SME),以类似方式提高 Exchange 备份速度。我们在 SME 中添加了单个邮箱恢复功能,帮助恢复丢失的单封邮件,而不必从 VTL 或磁带恢复。我们有 18 个远程办事处,因此我们的业务在很大程度上要依靠电子邮件来完成。现在有了这个功能,我们每周都可以恢复由于各种原因误删的邮件。我们还会进一步利用 SnapManager for Oracle ,不过事先会安排数据库管理员接受培训,让他们了解该软件在 Oracle 环境中的优势。

尽管 SnapManager 工具对我们的备份策略来说非常重要,但是此类工具也有不支持的应用程序。例如,我们有一些使用 Sybase 的旧应用程序。虽然没有适用于 Sybase 的 SnapManager,但是我们能够使用 NetApp SnapDrive® 及其提供的 API,为此数据提供级别相当的备份功能。您可以阅读以前的一篇 Tech OnTap® ,了解关于 NetApp SnapManager 工具和 SnapDrive 的详细信息。(NetApp 最近发布了 Snap Creator™ Framework ,目的在于进一步促进应用程序集成。)

我们在不同情况下使用的快照计划取决于特定数据集的要求。有些应用程序每小时备份一次,而其他应用程序则每天或每周备份一次。

我们依靠 CommVault 来完善备份策略。对于 NetApp Snapshot™ 未复制或以其他某种形式提供保护的数据,我们会使用 CommVault 将其备份到虚拟磁带库 (VTL)。我们在每个位置都有 VTL,不同位置之间相互复制数据。在灾难恢复站点,我们也会将 VTL 和 NetApp 存储备份到磁带,按照规定进行归档和异地存储。

灾难恢复

对于我们使用的旧式直连存储配置来说,在线灾难恢复几乎是不可能实现的,因此我们只能从异地磁带进行恢复。将所有数据整合到集中的 NetApp 存储极大地简化了这一流程,极大地提高了我们的灾难恢复能力。

我们使用 NetApp SnapMirror® 软件,将第一层的所有数据异步复制到灾难恢复站点。与 Snapshot 复制计划一样,SnapMirror 复制计划也是根据数据集的需求而制定的。某些数据复制频繁,每半小时就会复制一次。

我们使用 SnapManager 工具对 SQL Server 和 Exchange 数据的复制进行配置和管理。在每个复制周期中,会为源系统中的数据自动创建一致的 Snapshot 副本,这样在复制完成之后,可根据需要从灾难恢复站点中的数据立即恢复。

我们最近刚刚开始使用 VMware Site Recovery Manager (SRM) ,我们将使用该软件自动执行 VMware 环境的灾难恢复流程。SRM 可以帮助我们执行一些必要的步骤,包括灾难恢复站点中虚拟机的连接、资源清点、重新配置和启动。手动执行这些任务非常复杂,虚拟机启动顺序存在依赖关系时更是如此。SRM 可简化包括发现和配置、故障转移和灾难恢复测试在内的整个灾难恢复流程的管理。

存储效率

NetApp 给我们带来的另一项优势是帮助我们显著提高了整体存储效率。除上述节省空间的 Snapshot 副本和复制功能之外,我们还在很大程度上依赖 NetApp 精简配置和重复数据删除功能。

在 NetApp 系统上配置的所有存储几乎都已进行了精简配置。这样一来,多个卷可以共享单个空闲存储池,为我们节省了大量的空间。另外,我们很早就开始实施重复数据删除 — 现在,NetApp 仍然会先对每个安装的存储系统实施重复数据删除,然后再投入使用。考虑到我们现有的数据类型,我们主要对 VMware 数据存储库和 CIFS 共享使用重复数据删除。

截至目前已取得的进展

我们的 IT 基础架构改进工作任重而道远,但是现在我们已经取得了不小的进展。我在简介部分已经介绍了业务方面的显著改善。单纯从 IT 角度来看,我们经历了重大转型,取得了长足进展:

  • 提高了可靠性和可用性。 非计划停机和计划停机显著减少。借助 NetApp 集群系统,我们只需停止一个存储控制器就能进行一切必要的维护,同时不会影响正常业务运营。而 VMware VMotion™ 给服务器带来了相同的功能。
  • 提高了效率。 精简配置和重复数据删除帮助我们极大地节省了空间。我们发现,经过重复数据删除的卷最多可节省 58% 的空间。目前,我们分配的容量约为 260 TB。如果不使用精简配置和重复数据删除,我们就要分配约 350 TB 的容量。这多出来的约 35% 的存储需要占用机架空间、耗电,还要占用管理资源。
  • 在不增加人手的情况下增加存储。 我们增加了存储容量和存储系统,但所有存储系统的管理只需 1.5 个全职等效 (FTE) 员工。这在很大程度上是因为所有 NetApp 系统(无论是小还是大,不管使用何种协议)可以使用相同的界面、工具和命令进行管理。无论我们升级还是添加新系统,训练有素的员工都能轻松管理。
  • 简化管理和微调性能。 我们使用 NetApp Operations Manager(现属于 NetApp OnCommand™ )和 Performance Advisor 等 NetApp 管理工具来管理和掌握存储的情况。借助这些工具,当现有控制器上的存储负载达到需要交换机头的程度(如上所述)时,我们立即就能看到。如果数据库管理员报告了性能问题,我们也使用这些工具来判断问题是否与存储相关,然后确定问题的原因。

云计划

在未来的几个月中,Be The Match 将不断发展和演变基础架构,目标是创建一个完全虚拟化的共享基础架构,采用最佳技术满足患者和供者的需求。从软件的角度来看,我们会将开发重点放在核心需求(供者和患者配型)上,同时利用现成的最佳软件来满足其他需求。

演变的后续步骤之一是创建私有云,便于我们的内部开发人员请求和获得完全配置的虚拟服务器,而无需管理人员介入。我们打算将 NetApp 和 VMware 技术用作该计划的关键要素。我们还计划将基于 NetApp 存储的基础架构演变成公共云。如此一来,遍布 40 个国家或地区的附属组织网络便可利用 Be The Match 首创的先进技术,履行一项真正的全球使命,让越来越多身患绝症的患者有机会获得重生。

 对 Be The Match 有任何见解?

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

Josh Thorstad, IT 企业架构团队基础架构架构师, Be The Match

在过去 14 年中,Josh 一直在 IT 部门任职,他最初是一名帮助台初级人员,此后在 UNIX、网络和存储管理等部门担任过多个职位,现已升任基础架构架构师。他已在 Be The Match 工作了七年,现在负责包括服务器、网络、电信、存储和中间件在内的所有方面的基础架构规划工作。Josh 在之前的公司积累了使用 NetApp 存储的经验,在 Be The Match 引入 NetApp 存储的过程中,Josh 功不可没。


Tech OnTap
立即订阅
Tech OnTap 每月发布一次,为用户提供 IT 见解,以及对实际应用的最佳实践、技巧和工具、幕后技术访谈、演示、同行评论等的独家访问。

请访问 www.netapp.com/cn/communities/tech-ontap立即订阅。

Explore
Explore
关于 Be The Match

Be The Match 号召越来越多的人帮助那些需要非亲缘供者骨髓或脐带血移植的患者。Be The Match 由美国国家骨髓捐献计划 (NMDP) 运营,NMDP 是骨髓和脐带血移植领域的领导者,倡导大众挽救他人的生命,让患有白血病,淋巴瘤和其他危及生命的疾病的人有机会获得重生。志愿者可以加入 Be The Match Registry — 世界上最大、最多元化的潜在骨髓供者和脐带血捐献资料库,也可以向 Be The Match 基金会捐款或抽时间参与相关活动。 >更多内容

Explore
TRUSTe
联系我们   |   如何购买   |   反馈   |   招聘  |   预订   |   隐私策略   |   © 2011 NetApp