【IT168 技术】从概念验证(POC，proof-of-concept)到生产环境部署，客户在迁移到SAP HANA内存数据库平台之前需要考虑许多因素，其中包括硬件选择，备份与恢复计划以及安全性管理等等。

　　但客户究竟该从何入手呢?

　　理解HANA的架构

　　首先，你需要理解HANA并不是一个黑盒子;你可以把它看做是一个运行在特定硬件设备(有很多内存)上的Linux操作系统，它并不是一个简单的兼容SQL92的内存数据库。说到对于Linux的支持，HANA最早是部署在SUSE Enterprise 11上的，而目前新版HANA还支持RHEL 6.5。在部署之前，你需要仔细阅读SAP的产品指南。

　　HANA还是一个应用服务器，但并不是基于传统的SAP NetWeacer Application Server那样的ABAP或Java技术。它是一个精益的Web应用服务器，能够运行强大的内建SAPUI5或JavaScript的Web应用。

　　硬件选择

　　在硬件方面，SAP提供了许多经过认证的硬件厂商合作伙伴。今年早些时候，SAP还开放了硬件限制，客户可以在购买HANA许可证之后使用自己的硬件来运行。尽管仍然需要对硬件的配置进行特殊安排，比如内存、固态硬盘用来存储日志文件，高速硬盘存放数据，内存与CPU核心需要有固定比例，但此举无疑让SAP HANA的硬件选择范围得到了极大的扩展。同时，SAP目前已经运行客户自己进行HANA的部署了。在今年5月，VMware也通过了SAP认证，可以支持1 TB的HANA实例虚拟化。更多的硬件以及虚拟化合作伙伴，意味着SAP HANA将为客户提供更多的备份与恢复选项。

　　那么在进行HANA部署环境规划的时候，我们可以参考传统的三层系统环境方式，做到每一个实例与其他实例之间的隔离。举例来说，我们可以针对每一个软件开发生命周期中的元素选择一个单独的硬件：一个用于开发环境，一个用于质量保证(QA)，一个用于生产环境。这里要注意，HANA不支持每个服务器部署一个以上的数据库，因此沙箱和开发可以用一台服务器，而 QA和培训则需要另外另外一台服务器。

　　HANA还支持分布式的部署，其中包含一个控制(Master)节点和若干工作(Worker)节点，这样就可以非常轻松地构建一个QA环境来匹配生产环境的场景。比如两个节点可以支持单一的HANA开发实例以及一个分布式的QA实例。

　　备份与恢复策略

　　当针对生产环境进行硬件规划的事后，我们还需要充分考虑到备份策略以及灾难恢复需求。在我看来，“双活”环境的每一个主机都能接收请求，如果一个主机宕机，客户端连接可以迅速地重启。但在HANA环境当中，SAP并没有提供这样的双活集群配置。他们提供了一个自动化的主机故障转移功能，也需要做一些DNS的变更。能不能做到立即切换?答案是否定的。但切换速度快不快?答案是肯定的。

　　我们可以使用一个复制的备用系统，它可以在几分钟之内完成故障转移，但它称不上是真正高可用，比如NetWeaver那样。在复制备用数据库场景下，要记住两个关键点：第一，在灾难场景下，我们需要通过DNS变更来重新定向客户端数据库请求;第二，我们可以利用备用数据库作为其他实例的非生产环境数据库，比如QA与测试。根据我的经验，备用数据库场景下SAP提供了非常好的灵活性，而且SAP在让客户充分利用硬件方面投入了很多研发精力，使得客户数据中心里的每一台机器都能够物尽其用。

　　在HANA中进行备份是非常简单的，每一个数据中心管理者与中层IT人员对此应该都不陌生。我们必须经常进行数据库和日志文件的备份以便能够提供一个即时恢复能力。我们可以通过SAP HANA Studio或者在操作系统层面上使用命令行来进行数据库备份，这些都是开箱即用的功能。当然也有一些客户选择了SAP的合作伙伴来进行备份，比如Symantec、IBM、HP等等，而针对备份的SAP认证叫做HANA-BRINT 1.1，你在SAP官网上搜索它就可以出现许多备份的产品。

　　管理员技能

　　现在，我们已经理解了HANA的架构，接下来的问题就是：“我们该做哪些准备?我们如何进行备份?”此外，部署HANA对企业内部资源的技能集也是有特定要求的。从管理角度来说，SAP Basis管理员如果在UNIX平台方面有足够的经验的话，那么他可以非常轻松地理解并上手HANA。整个HANA的部署机制都和SAP非常相似。我们需要将HANA连接到SAP Solution Manager for Enterprise SupportServices，这是在NetWeaver平台上最常见的Basis任务。而使用内存数据库的确需要在系统监控方面添加其他维度，Basis管理员需要对新技术敞开胸怀并迎接新的挑战。另外，SAP在实时与历史数据分析方面也为我们提供了足够多的好用的工具。

　　安全性考虑

　　对于已经有专门的安全团队来管理SAP Business Suite或其他基于NetWeaver应用的企业来说，在HANA中管理安全性是变化最大的一个方面。如果你在HANA上运行NetWeaver BW 或 SAP Business Suite，那么对于安全团队的工作并不会有太大影响。但如果你选择把HANA部署为一个单独的数据仓库或者应用服务器的时候，那么安全团队就需要大量时间来学习新的架构和功能。在HANA中究竟谁来负责安全性?对于我来说仍然是一个让人迷惑的问题。在传统的数据库管理系统中，DBA处理基本的数据库维护之外还要全权负责数据库安全的工作。而在SAP NetWeaver环境中，由于SAP把安全性工作放到了应用层，因此在数据库层面基本不要担心安全问题。Basis管理员称不上是好的安全管理员，如果我在进行生产环境的HANA部署，我就会仔细考虑由谁来负责HANA的安全性管理工作。

　　Solution Manager

　　此外，还有很多客户对于HANA中的Solution Manager的使用存在误解。Solution Manager仍然是HANA系统预警报告(Early Watch Reports)的唯一实现机制，同时也是SAP持续质量监测的载体，后者已经包含在所有SAP客户的标准化或企业维护协议当中。那些投入大量资金在HANA部署上的客户，在正式上线之前一定要利用好SAP的Going Live认证服务以及主动监控功能，这些功能都包含在SolutionManager当中。

　　部署HANA的确是一件充满挑战的任务，然而通过团队协作与知识分享，你的新项目将会为企业带来新的价值。HANA的潜力非常大，等待着每一个企业去开拓。

　　原文链接：http://www.searchdatabase.com.cn/showcontent_84151.htm