网上科普有关“如何解决服务器虚拟化中的存储问题？”话题很是火热，小编也是针对如何解决服务器虚拟化中的存储问题？寻找了一些与之相关的一些信息进行分析，如果能碰巧解决你现在面临的问题，希望能够帮助到您。

但也因为虚拟化的特性，为承载环境中不断增长的虚拟机，需要扩容存储以满足性能与容量的使用需求。IT经理们已经发现，那些因服务器虚拟化所节省的资金都逐渐投入存储购买的方案上了。 服务器虚拟化因虚拟机蔓延、虚拟机中用于备份与灾难恢复软件配置的问题，让许多组织彻底改变了原有的数据备份与灾难恢复策略。EMC、Hitachi Data System、IBM、NetApp和Dell等都致力于服务器虚拟化存储问题，提供包括存储虚拟化、重复数据删除与自动化精简配置等解决方案。 服务器虚拟化存储问题出现在数据中心虚拟化环境中传统的物理存储技术。导致虚拟服务器蔓延的部分原因，在于虚拟服务器可能比物理服务器多消耗约30%左右的磁盘空间。还可能存在虚拟机“I/O 搅拌机”问题：传统存储架构无法有效管虚拟机产生的混杂模式随机I/O。虚拟化环境下的虚拟存储管理远比传统环境复杂——管理虚拟机就意味着管理存储空间。解决服务器虚拟化存储问题 作为一名IT经理，你拥有解决此类服务器虚拟化存储问题的几个选项，我们从一些实用性较低的方案开始介绍。其中一项便是以更慢的速度部署虚拟机。你可以在每台宿主上运行更少的虚拟机，降低“I/O混合器”问题出现的可能性。另外一个方法则是提供额外存储，但价格不菲。 一个更好的选择是在采购存储设备时，选择更智能的型号并引入诸如存储虚拟化，重复数据删除与自动化精简配置技术。采用这一战略意味着新技术的应用，建立与新产商的合作关系，例如Vistor、DataCore与FalconStor。将存储虚拟化作为解决方案 许多分析师与存储提供商推荐存储虚拟化，作为服务器虚拟化存储问题的解决方案。即使没有出现问题，存储虚拟化也可以减少数据中心开支，提高商业灵活性并成为任何私有云的重要组件之一。 概念上来说，存储虚拟化类似服务器虚拟化。将物理存储系统抽象，隐藏复杂的物理存储设备。存储虚拟化将来自于多个网络存储设备的资源整合为资源池，对外部来说，相当于单个存储设备，连同虚拟化的磁盘、块、磁带系统与文件系统。存储虚拟化的一个优势便是该技术可以帮助存储管理员管理存储设备，提高执行诸如备份/恢复与归档任务的效率。 存储虚拟化架构维护着一份虚拟磁盘与其他物理存储的映射表。虚拟存储软件层(逻辑抽象层)介于物理存储系统与运行的虚拟服务器之间。当虚拟服务器需要访问数据时，虚拟存储抽象层提供虚拟磁盘与物理存储设备之间的映射，并在主机与物理存储间传输数据。 只要理解了服务器虚拟化技术，存储虚拟化的区别仅在于采用怎样的技术来实现。容易混淆的主要还是在于存储提供商用于实现存储虚拟化的不同方式，可能直接通过存储控制器也可能通过SAN应用程序。同样的，某些部署存储虚拟化将命令和数据一起存放(in-band)而其他可能将命令与数据路径分离(out-of-band)。 存储虚拟化通过许多技术实现，可以是基于软件、主机、应用或基于网络的。基于主机的技术提供了一个虚拟化层，并扮演为应用程序提供单独存储驱动分区的角色。基于软件的技术管理着基于存储网络的硬件设施。基于网络的技术与基于软件的技术类似，但工作于网络交换层。 存储虚拟化技术也有一些缺陷。实现基于主机的存储虚拟化工具实际上就是卷管理器，而且已经流传了好多年。服务器上的卷管理器用于配置多个磁盘并将其作为单一资源管理，可以在需要的时候按需分割，但这样的配置需要在每台服务器上配置。此解决方式最适合小型系统使用。 基于软件的技术，每台主机仅需要通过应用软件查询是否有存储单元可用，而软件将主机需求重定向至存储单元。因为基于软件的应用通过同样的链路写入块数据与控制信息(metadata)，所以可能存有潜在瓶颈，影响主机数据传输的速度。为了降低延迟，应用程序通常需要维护用于读取与写入操作的缓存，这也增加了其应用的价格。服务器虚拟化存储创新：自动化精简配置与重复数据删除 存储技术的两个创新，自动化精简配置与重复数据删除，同样是减少服务器虚拟化环境对存储容量需求的解决方案。这两项革新可以与存储虚拟化结合，以提供牢固可靠的存储容量控制保障。 自动精简配置让存储“走的更远”，可减少已分配但没有使用的容量。其功能在于对数据块按需分配，而不是对所有容量需求进行预先分配。此方法可以减少几乎所有空白空间，帮助避免利用率低下的情况出现，通常可以降低10%的磁盘开销，避免出现分配大量存储空间给某些独立服务器，却一直没有使用的情况。 在许多服务器部署需求中，精简配置可通过普通存储资源池提供应用所需的存储空间。在这样的条件下，精简配置可以与存储虚拟化综合应用。 重复数据删除从整体上检测与删除位于存储介质或文件系统中的重复数据。检测重复数据可在文件、字节或块级别进行。重复数据删除技术通过确定相同的数据段，并通过一份简单的拷贝替代那些重复数据。例如，文件系统中有一份相同的文档，在50个文件夹(文件)中，可以通过一份单独的拷贝与49个链接来替代原文件。 重复数据删除可以应用与服务器虚拟化环境中以减少存储需求。每个虚拟服务器包含在一个文件中，有时文件会变得很大。虚拟服务器的一个功能便是，系统管理员可以在某些时候停下虚拟机，复制并备份。其可以在之后重启，恢复上线。这些备份文件存储于文件服务器的某处，通常在文件中会有重复数据。没有重复数据删除技术支持，很容易使得备份所需的存储空间急剧增长。改变购买存储设备的观念 即使通过存储虚拟化，重复数据删除与精简配置可以缓解存储数容量增长的速度，组织也可能需要改变其存储解决方案购买标准。例如，如果你购买的存储支持重复数据删除，你可能不再需要配置原先规划中那么多的存储容量。支持自动化精简配置，存储容量利用率可以自动提高并接近100%，而不需要管理员费心操作维护。 传统存储购买之前，需要评估满足负载所需的存储能力基线、三年时间存储潜在增长率、存储扩展能力与解决存储配置文件，还有拟定相关的采购合同。以存储虚拟化与云计算的优势，购买更大容量的传统存储将越来越不实际，尤其在预算仍是购买存储最大的限制的情况下。以下是一些简单的存储购买指导： 除非设计中明确说明，不要购买仅能解决单一问题的存储方案。这样的做法将导致购买的存储架构无法与其他系统共享使用。 ·关注那些支持多协议并提供更高灵活性的存储解决方案。 ·考虑存储解决方案所能支持的应用/负载范围。 ·了解能够解决存储问题的技术与方案，例如重复数据删除与自动化精简配置等。 ·了解可以降低系统管理成本的存储管理软件与自动化工具。 许多组织都已经在内部环境中多少实施了服务器虚拟化，并考虑如何在现有存储硬件与服务器上实现私有云。存储预算应用于购买合适的硬件或软件，这点十分重要。不要将仅将注意力集中在低价格上。相反，以业务问题为出发点，提供解决问题最有价值的存储解决方案才是王道。

　企业架构与业务优化有关 后者用来解决企业架构 绩效管理 组织结构和流程架构等问题 它包含对组织的流程 信息系统 人员和业务等单元的当前及将来的结构及行为的描述 以确保上述单元能够符合组织的战略发展方向 可见 企业架构的概念超越了信息技术的范畴

　企业架构与信息技术紧密相关 在本文中 我将描述SOA（面向服务的架构）环境中的一种简化的 自上而下的企业架构 重点关注信息技术 目的是实现业务和IT间的最佳看齐

　我将介绍

自上而下的企业架构方式的不同关注点 企业架构的目标 方法论概述 与 BEA SOA 域模型的关系

　通过本文 您将能很好地理解由业务策略驱动的自上而下的企业架构方式 该方式的优势以及相关的组织方面的考虑

自上而下的企业架构方式的不同关注点

　在自上而下的方式中 从业务到IT 很有必要在不同的规划分离业务和IT的不同关注点 进而在二者之间奠定公共的基础 与业务相关的规划被称为业务流程规划 与IT 相关的规划被称为应用规划 而二者之间的规划——也是该方式中最有意义的部分 因为这种方式旨在提供业务和IT间的最佳看齐——则被称为功能规划 若要描述硬件 网络 操作系统 应用服务器和数据库等 则可引入技术规划的概念 我无意详细描述技术规划 因为我的主要目的是推荐一种方式来通过公共的基础实现IT和业务间的最佳看齐

　图 描述了这些规划以及它们之间的相互关系 我将对其详细加以介绍

　

　

　图 自上而下的企业架构方式的不同关注点

业务流程规划

　此规划侧重于业务战略环境中的业务流程 可与组织中的不同业务线紧密合作的企业架构从由业务战略定义的业务需求开始 并能为主要的企业业务流程建模 比如 企业架构可通过AquaLogic BPM Designer在设计层面实现这一目的 这将有助于架构师理解企业内全局的主要流程 而且通过让更多的销售代表参与进来还可以推进这种方式 使用AquaLogic BPM Designer 业务分析师可以模拟业务流程 提供在对流程进行反向工程时发生的优化的一种度量 业务流程规划归业务本身所有 架构师的主要任务是获取业务需求并确认可由组织内的不同业务线使用的共同业务服务

　以银行业务环境为例 首先要先设计各项银行业务（比如贷款 进/出口操作）的流程 这两项银行业务具有完全不同的流程 但也会共享一些共同的服务 共同服务的确认是通过在组织层面设计流程实现的 在某种程度上 授权系统和会计系统应该能在不同的流程 比如开具信用证（LC）的流程或贷款批准的流程 被重用 两个流程应该能使用共同的授权服务和共同的会计服务

功能规划

　设计好组织的重要流程之后 就可用确定主要的功能块了 功能块提供可在不同的业务流程中重用的业务服务 业务服务也是 SOA 理想的构建块 这些服务还应该能被重用和重组 以便提供业务所需的敏捷性 在选择这些功能块以及需要在功能块间共享的数据时 业务线应该提供给企业架构师足够的业务知识 以便整个组织都能重用和理解规范的数据模型 域UML模型和数据存储库 这之后 就需要在规划中加入业务

　这种通用的做法应该会带来可在整个组织内共享的通用的语言和通用的分类法 通用实体和通用域模型的定义使其在组织内的含义通用 而且可以被不同的业务线重用 这个规划就像是个城市规划 将功能构建块组织成与组织内不同的业务线相关的区域和地带

　通用的语言将十分有助于功能构建块的重用以及数据在这些块间的共享 规范模型应该在企业存储库内被共享 管理考虑应该定义设计 访问 验证和修改这些模型的方式 我将在本文后面的部分对这些考虑事项详加介绍

　回到银行这个例子 在这个组织中 应该有一个业务线用来处理付款 外币兑换和抵押 另一个业务线处理贷款 第三个业务线处理进/出口操作 比如信用证（LC）和收款 还有一个水平的业务线用来处理授权 会计 报告以及风险管理 如果用城市规划来做比喻的话 每个业务线都可看作一个特区

　进一步观察进/出口这个业务线 还会发现分别与LC和收款相关的功能块 而代表LC 的功能块还可以细分为LC所应提供的不同的服务 这个块应该提供功能（或服务） 比如开具LC 修改LC 使用LC和偿还 LC 这些都是LC块的业务服务 这些服务将依赖于由授权块 会计块和付款块提供的功能

　授权块将基于客户的状态为客户授予信贷额度 授权块可能会依赖于风险管理块的功能 LC功能也将使用由会计块和付款块提供的服务 而付款块则将会使用会计块和授权块的功能

　对功能规划的描述采用业务术语 并加以细分以使它能映射到应用内的应用程序和服务 在银行示例的这个环境中 会计服务和授权服务在组织层面上重用

　确定了这些功能构建块之后 还需要定义这些块之间的通信 这就意味着形成规范的数据模型 这个规范模型可使用UML模型进行描述 这就带来了数据的XML表示 这个通用语言应该跨整个组织共享

　在银行示例中 不管是在LC块还是在贷款块使用 账户都是一样的 客户也是相同的 账户和客户都是在跨组织的共享业务模型中定义的实体 这些实体由两个规范模型表示 一个用于账户数据 另一个用于客户数据 这些模型可由整个组织共享 它们可通过作为组织构建块的一部分的公共服务访问 这些服务可以是 CRUD (Create Retrieve Update Delete) 服务 也可以是复合服务 定义规范模型的最好的方法是参考业界标准 银行系统使用SWIFT 标准 在 SWIFT标准手册中定义的 MT 消息在业务用例使用消息的层面上定义了银行操作 这些消息可以轻松映射成可在整个组织内使用的 XML 消息 最大限度地遵循标准非常有助于将单个组织内使用的业务操作扩展到多个组织间的B B 操作

　在Quinton Wall撰写的 理解SOA中的服务生命周期 设计时 和 理解SOA中的服务生命周期 运行时 中有关于服务设计 建模和运行时关注点的更多信息

　定义了块中使用的功能块和数据模型后 这些资产应该能由企业存储库中的不同业务线重用 BEA AquaLogic Enterprise Repository 可用来共享企业信息资产

应用和实现规划

　正如我所提到的 功能构建块是SOA构建块的理想选择 使用自上而下的方式确定的服务将会带来业务需求和IT间更好的匹配

　应用规划中的服务实现将取决于服务的类型以及服务与不同的SOA 层间的关系 这些层包括表示和复合层 编排层 业务服务层和数据访问层或连接层

　为实现这些块选择合适的产品时 要格外慎重 应该考虑组织的环境 比如现有的应用程序和技术限制 当进行实现方面的选择时 应用规划与技术规划是分不开的 在理想情况下 BEA WebLogic Integration 是系统到系统过程的一种不错的选择 用于业务流程规划中的设计和流程再设计的BEA AquaLogic BPM是人工驱动流程的理想选择 BEA WebLogic Portal 非常适合在整个组织内通过WSRP开发和共享表示层 进而促进表示层和门户联邦的重用 AquaLogic Data Services 是数据访问层的一种理想工具 而AquaLogic Service Bus 则非常适用于应用程序到应用程序的通信 在实际环境中 这些选择取决于组织内现有的资产和需求 另外 应该在组织的环境中考虑使用参考架构

　组织的参考架构是能够根据其所属的层和服务提供如何实现每个构建块的最佳实践和蓝图 在参考架构中还会定义和显示服务间的通信 图 给出了为组织定义的一个参考架构示例 此图表还描述了通过合适的产品实现组织的功能构建块服务所需的 SOA 层 参考架构的定义通过涉及合适的业务和IT层的流程实现 这种模型可用于在组织环境内针对每个SOA层实现构建块

　

　

　图 组织的参考架构

　参考架构应能有助于推广由管理团队定义的最佳实践 指导原则和设计原理 此架构应该使用在功能规划中定义的规范的模型和分类法 我将在稍后讨论管理团队的有关内容

企业架构的目标

　采用从组织的业务需求开始的全局手段 企业架构的主要目标是借助通用语言构建重用的氛围 如图 所示 这一目标应该逐渐实现而不是依靠急剧变革一蹴而就 应该有一个管理团队来管理不同的范畴 全局业务和战略范畴 信息系统范畴和项目范畴 应该支持通过合适的工具来促进整个组织内的重用

　

　

　图 企业架构的目标

管理团队

　管理团队应该创建和维护反映组织当前状态的资产 比如现有的功能模块 在这些资产中 有对当前状态的全局描述 这将十分有助于确定当前信息系统的筒仓（silo） 定义目标状态时还应考虑路线图

　要想将路线图应用到目标 管理团队应该在项目之初就介入 为整个组织提供指导原则 实施规定以及最佳实践

　指导原则 策略 分类法 企业规范数据模型 数据存储库 最佳实践 可重用资产以及需要由管理团队定义和维护的其他准则会触及所有的业务线以及IT

全局业务和战略范畴

　企业架构应该能够协调IT与组织的战略 它应该能轻松适应业务的不断变更 这就要求业务架构和指导原则必须能够最终形成组合和分解业务流所需要的功能构建块

信息系统范畴

　企业架构团队引用现有的功能构建块 它也可以定义业务处理所需的新的功能构建块 正如在业务流程规划中的全局业务范畴中定义的那样 信息系统范畴与功能规划相关 并应该能够通过可由业务和IT所理解的语言来提供正确的抽象级别

　信息系统资产在功能规划中定义 该定义包括在功能级别应用程序间的通信以及规范的企业数据模型 通用语言 分类法以及数据存储库 应该定义和控制对这些资产的访问

　功能规划中的工作应该与应用规划中的应用相对应 各种标准和产品支持应该与每个应用所涵盖的方面联合确定

项目范畴

　在运营的层面上 大多数举措都应该以项目的方式实现 以确保成功应用各项指导原则和规则 来自管理团队的架构师应该确保详细的技术要求和项目架构与企业的指导原则 策略以及企业通用语言的使用相一致 若能在投资的早期就向可交付项目应用架构蓝图将能显著增加符合规定 具有更好可重用性的按时 按预算 保质交付的可能性 只有这样 项目才能提供新的可在整个组织重用的SOA构建块

　将全局驱动的策略应用到新的项目是一种实现目标的演进式的方案 过程是平滑进行的而非爆炸式的变革

企业架构存储库管理

　对企业常规模型定义的访问应该全局可用以便开发一种通用的企业语言 使用通用的分类法 没有通用的语言就无法实现重用 信息系统资产的有效管理可通过使用企业存储库实现 这个存储库应该能由整个组织访问 并由管理团队管理 它应能提供资产和元数据的扩展视图 BEA AquaLogic Enterprise Repository 是可用来支持企业架构的一种优秀工具

方法论概述

　设计企业架构的一种优秀方法是描述上述每个规划的当前状态 如图 所示 这将有助于评估业务和IT间的差距并确定简仓 然后 可定义路线图来实现目标 方法论实际上就是分析在本文的开始所描述的不同的规划来评估当前状态和定义目标状态

　

　图 方法论概述

当前状态（既有的）

　当前状态的评估可以用自上而下的方式 自下而上的方式或两种方式的混合来实现 当前状态的定义可在每个规划上进行

　从业务流程开始 通用的工作应该由业务线和IT共同实现以定义业务流程的当前状态 用AquaLogic BPM Designer对这些流程建模可以为架构师和业务代表提供共同的基础 可使用AquaLogic BPM位业务流程及模拟可能性绘制增强的图形

　从现有的应用开始 联合IT 确定现有的功能块 这样 重复的功能才有可能出现 筒仓才会被识别出来

　一旦识别了筒仓应用程序 就应该在目标状态定义通过服务公开消除筒仓的方法

目标状态（应有的）

　定义目标状态应该采取自上而下的方式 这是推荐的方式 原因是它构建在业务需求之上并能提供可重用的业务构建块

　从业务流程开始 与业务线合作 可通过使用AquaLogic BMP Designer对优化后的未来状态流程建模 再下来 确定功能块 提供业务流程的复合和分解所需的服务 请记住 在功能规划中 只有业务和IT联合才能完成共同的任务

路线图

　之后 定义路线图来实现中间 认可状态的目标 这个路线图在定义通用语言 规范模型 数据存储库时应该被考虑进去 中间的验证步骤应该涉及业务和IT

　参考架构在路线图的某些阶段规划 当然 参考架构的规划可以在任何时候进行 但您不应等到所有企业资产都定义好后才开始准备参考架构 有效的资产应该不断针对新的业务需求进行调整（新的功能块会涉及新的实现方法） 它的目标是根据目前所存在的企业可重用资产以及应该被采用的技术给出 如何做 的指示 如前面提到的 参考架构处在不断的发展之中 提供了一种在某些时候以增强的可重用性为目标在组织的环境中实现新项目的最佳方法

　管理团队是路线图中涉及到的最主要的团队 原因是该团队可在整个新项目过程中借助其所生成的资产全局参与并侧重于提供业务所需的敏捷性 管理团队应该包括一组具有不同专业背景的企业架构师 这样他们就可以在不同程度上关注其中的某个规划 主导管理团队的应该既有侧重于技术的架构师 也有侧重于业务的架构师 管理团队可以由源自不同业务线的资深架构师和源自IT的资深架构师混合组成 这就使团队具备了领导全局的必要资质

　管理团队的任务在某些环境中实现起来很困难 所以应该提供强有力的协助 管理团队的角色多少有些像炼金术士 致力于寻找正确的 配方 以催生合适的转变 在这方面 有很多文章可以参考 比如David Groves 和 Steve Bennett 所著的 成功规划SOA 成功规划SOA 构建您的SOA路线图 以及 成功规划SOA 进行长期SOA规划 请注意在应用路线图之前务必要考虑变更管理

与BEA SOA 域模型的关系

　这里所描述的方式以业务策略和流程为起点 通过功能构建块构成应用 所有这些都可通过通用的企业语言以及可为新项目和应用提供蓝图的参考架构实现 在功能规划中 我介绍了为了维护结构化的视图和成功公开可在整个企业共享的资产需要由组织处理的各个方面

　在使用SOA作为企业架构的环境中 资深的SOA架构师需要避免代价昂贵的常见缺陷 这些架构师应该与组织的管理团队协作来提供所需的技能并帮助管理团队建设成功的SOA SOA可以以企业方式全局驱动 也可以在项目中局部驱动 采取全局的方式可以为项目提供管理和指导 进而可以为SOA提供更高的一致性和更好的投资回报 它会减少生产中的应用程序的维护费用 增强其可重用性

　BEA 提供了一种域模型 可用来处理企业架构 这一模型通过六个方面涵盖了之前所描述的规划（以及更多） 提供了一种成功实现SOA的途径 如图 所示

　

　图 BEA域模型

　BEA SOA方式是一种注重实效的企业架构方式 它触及了信息技术的各个方面 BEA 提供了针对所有六个方面的服务和培训 而且进行了有效的组织以让您能够实现SOA来满足您组织自身的需求

　开始时 不妨参考一下BEA SOA Readiness Asses *** ent Report 它可帮助您定义当前的状态 是在组织中引入SOA的一个很好的起点 通过在 SOA Resource Center 参加一个调查就可以收到SOA 的评估报告

结束语

　本文展示了自上而下的企业架构 介绍了获得跨组织的全局可重用性所需要的管理关注点 强调了组织的参考架构的必要性 定义了企业存储库以促进这种全局方式

　 原文出处 l

?作者简介 Gabriel Bechara Gabriel Bechara 已经为BEA咨询服务部门工作两年多了 Gabriel帮助客户使用BEA的产品 比如WebLogic Server Portal和Integration Gabriel的兴趣包括定义软件架构的方法 在开发团队中使用产品以及提供将应用程序推向生产的最轻松方式 主要关注WebLogic Integration以及与SOA相关的方法 Gabriel加入软件行业已有 年多了 Gabriel与妻子及两个孩子居住在巴黎唐人街 lishixinzhi/Article/program/Java/ky/201311/28398

关于“如何解决服务器虚拟化中的存储问题？”这个话题的介绍，今天小编就给大家分享完了，如果对你有所帮助请保持对本站的关注！