业务部署（精选九篇）
业务部署 篇1
关键词：MPLS VPN,组网模型,网络部署,参数规划,应用实例
1 MPLS VPN简介
MPLS与VPN相结合后推出的MPLS-VPN, 是指采用MPLS技术在骨干的宽带IP网络上构建企业IP专网, 实现跨地域、安全、高速、可靠的数据、语音、图像多业务通信, 并结合差别服务、流量工程等相关技术, 将公众网可靠的性能、良好的扩展性、丰富的功能与专用网的安全、灵活、高效结合在一起, 为用户提供高质量的服务。
2 MPLS VPN网络部署
部署MPLS VPN现网设备必须支持MPLS技术, 而运行三层MPLS VPN, 需要运行MBGP, 运行MBGP必须首先启用BGP路由协议, BGP路由协议必须通过IGP进行承载。
因此在进行网络部署前, 首先要检查一下我们现有的网络是否具备部署条件, 为此需要确认以下问题:
(1) 我们现有的网络设备都有哪些支持MPLS技术。
(2) 我们现有的网络部署的是何种IGP路由协议, 是否部署了BGP。
(3) 我们开展MPLS VPN业务的范围是什么。
第一个问题确认好后, 我们就可以确认我们的网络中那些设备可以作为P或PE设备使用, 处于网络核心位置的设备作为P设备, 处于网络边缘的设备作为PE设备。
第二个问题:如果是较大型的网络, 一般都会启用OSPF或者IS-IS作为IGP, 大型的网络肯定会开启BPG路由协议。我们只需要确认目前的路由协议软件版本是否能够很好地支持部署MPLS VPN即可。
第三个问题是我们要部署的网络范围, 如果只在同一区域内, 则不会产生跨域问题, 如果需要开展不同区域的MPLS VPN业务, 则需要注意跨域问题。一般我们均先开本区域内的MPLS VPN业务, 业务较成熟后考虑推跨区域的MPLS VPN业务。
确认完以上问题后, 我们在所有的P和PE设备上开启MPLS, 启用BGP和MBGP, 这样我们的网络技术部署就完成了。
3 MPLS VPN的参数规划
MPLS VPN技术部署完成后, 就可以开展MPLS VPN业务了, 在开展MPLS VPN业务之前, 我们还要对相关参数进行规范, 以方便管理及辨认。
下面我们来认识一下开展MPLS VPN业务必须涉及到的一些参数:
VPN路由转发表, 也称VPN-instance (VPN实例) , 是PE为直接相连的site建立并维护的一个专门实体, 每个site在PE上都有自己的VPN-instance。
在MPLS VPN网络中, 对VPN的所有处理都发生在PE路由器上, 为此, PE路由器上起用了VPNv4地址族, 引入了RD (Route Distinguisher) 和RT (Route Target) 等属性。RD具有全局唯一性, 通过将8byte的RD作为IPv4地址前缀的扩展, 使不唯一的IPv4地址转化为唯一的VPNv4地址。
RT使用了BGP中扩展团体属性, 用于路由信息的分发, 具有全局唯一性, 同一个RT只能被一个VPN使用, 它分成Import RT和Export RT, 分别用于路由信息的导入和导出策略。在PE路由器上针对每个site都创建了一个虚拟路由转发表VRF (VPN Routing&Forwarding) , VRF为每个site维护逻辑上分离的路由表, 每个VRF都有Import RT和Export RT属性。当PE从VRF表中导出VPN路由时, 要用Export RT对VPN路由进行标记;当PE收到VPNv4路由信息时, 只有所带RT标记与VRF表中任意一个Import RT相符的路由才会被导入到VRF表中, 而不是全网所有VPN的路由, 从而形成不同的VPN, 实现VPN的互访与隔离。
在认识了以上参数的作用之后, 我们就需要对其进行规范:
VRF命名规则:
VRF命名要求通俗易懂, 容易区分。最好包含用户范围、用户名称等
如唐山范围内的用户可以标识为:ts-zhangsan
RD命名规则:
RD通常定为:AS:*****
AS可以区分不同的区域, *****可以包含用户类型、服务级别、序号等信息
RT命名规则:
RT export可以与RD同, import根据CE互访的需要灵活配置。
4 MPLS VPN业务应用实例
我们通过一个实例来看如何进行MPLS VPN业务应用。
4.1 用户网络现状
用户现有区网络承载在ATM网上, 目前用户有3个中心节点 (包括直属中心) , 5个区中心, 150个支点。
4.2 用户存在问题
用户网络存在的问题如下:
(1) 由于ATM网络限制, 支点的接入速率过低, 不能满足日益增长的终端数量及应用的需求.
(2) 用户侧ATM接入设备老化, 更换成本过大。
4.3 用户需求
保持现有网络结构, 各区中心可以管理本中心的设备和业务, 中心点可以管理全部的设备和业务。
4.4 业务组网方案
为满足用户提速和网络改造需求, 结合本地网络情况, 建议使用MPLS VPN技术为用户搭建虚拟专用网络。
网络拓扑如下:
该用户网络有1个总部、6个区域中心和多个分支点。总部管理全网的分支点业务, 区域中心可管理本区域内的分支点业务。
为用户组建6个MPLS VPN网络, 每个MPLS VPN网络承载1个区的所有支点;为用户搭建各区中心到用户中心的专网, 通过光纤搭建实际也可以采用第7个MPLS VPN网络来汇聚6个区到中心点的业务流量。
4.5 相关参数规划
根据全局规划, 此用户的MPLS VPN参数如下:
用户IP地址规划如下:
业务部署 篇2
一、统一思想，充分认识开展脱贫攻坚普查工作的重要意义
党的十八大以来，党中央、国务院把扶贫工作提高到了前所未有的高度，明确到2020年我国现行标准下农村贫困人口实现脱贫、贫困县全部摘帽、解决区域性整体贫困的目标任务。今年的中央一号文件和《政府工作报告》都对脱贫攻坚普查作出了部署要求，习近平总书记在2020年3月6日决战决胜脱贫攻坚座谈会上的讲话中强调：“要严把退出关，坚决杜绝数字脱贫、虚假脱贫。从下半年开始到明年初，国家将分两批组织开展脱贫攻坚普查这项工作，对各地脱贫攻坚成效进行全面检验。这是一件大事。普查数据将为党中央适时宣布打赢脱贫攻坚战、全面建成小康社会提供数据支撑，确保经得起历史和人民检验。”中共中央政治局委员、国家脱贫攻坚普查领导小组组长胡春华副总理在国家脱贫攻坚普查电视电话会议上强调，“要深入贯彻习近平总书记重要指示精神，按照党中央、国务院决策部署，扎实开展各项准备工作，做好脱贫攻坚普查这件大事，确保各项工作落实到位。”
EHR何时部署?怎样部署? 篇3
等待观望
虽然有补助资金和其他部署策略，很多医疗机构还是想等一等，暂不部署EHR。“虽然外部有刺激资金，但44000美元或65000美元需要分5年才能拿到。”Bell建议：“如果还没有准备就绪，又没有落实项目的计划，最好的选择还是等待，甚至可能要等到2013年，到时一批新的标准将会出台。”
如果诊疗所采取等待的策略，不但能满足高标准、有意义地使用EHR系统，还能满足病人护理和行政管理自动化方面的需求。如果等到2012年或2013年，就能确保符合第一阶段和第二阶段“有意义使用”的要求。
Bell说：“要做的第一步就是制定方案。坦率地说，许多医师诊所忽略了这一步。为什么你要部署该系统？要非常清楚现在的收入来源以及采用之后的收入来源，确定当下是否该积极推行EHR，还是应该再观望一阵子。”
专家们一致认为，EHR技术让医患双方都能受益。EHR让医生们可以以近乎实时的方式与病人及其他医生共享检验结果、放射影像和其他临床信息；还能减少与纸张有关的行政管理任务，最终有助于确保医护人员遵守所谓的循证医疗，采取最佳的治疗手段。此外，部署了EHR后，医生还能在病人床头或异地使用平板电脑和智能手机等无线设备。
调研公司IDC旗下Health Insights部门的分析师Judy Hanover建议:“医生和诊所在部署EHR系统之前，应首先进行差距分析，确定目前自己有什么、还需要什么，才能部署新系统。他们应该考虑需要什么技术来支持服务目标；应该把近期和长期的“有意义使用”要求以及将来在病人护理方面的目标都考虑进来。只有完成了这些工作，才可以向提供商提出征询方案。
放射科医生Tom Handler现在是调研公司Gartner的医疗行业分析师，Handler建议，医疗服务机构还应该考虑相关流程和协议。换句话说，他们应弄清楚如何为相互关联的每一家医师诊所和每一家医院部署的技术统一标准。另外，他们应该考虑是否需要某些功能（如医嘱集），作为事先已填好的医嘱模板成为计算机录入系统的一部分。
美国国家卫生信息技术协调办公室（ONC）在全美建立了66家区域推广中心（REC），明确旨在帮助医师诊所和乡村诊所部署EHR。区域推广中心不为医疗服务机构提供任何资金，但确实能在部署计算机系统方面提供培训和技术援助。每个区域推广中心有10〜30名员工，员工的人数取决于所在区域的规模。
美国政府还发放了1.44亿美元的专款，设立大学课程以培训人员。这有助于填补预计的5万个岗位空缺，旨在帮助医生和医院顺利部署EHR。不过，这笔款项不能支付与卫生IT有关的最基本成本——EHR的软硬件成本。
SaaS是个选择
节省部署成本的一个好办法就是选择软件即服务（SaaS）方案。提供商在自己的数据中心运行应用软件，同时通过安全网络为医护人员提供EHR功能。
Handler表示，如果选择SaaS这条路，就要清楚地了解自己购买的内容。声称拥有SaaS解决方案的提供商本质上销售的是托管服务。两者有何区别？如果是SaaS模式，软件驻留在提供商数据中心的服务器上，多个客户共享该数据中心，它往往不是定制品，而是成套完备的产品；托管服务则意味着提供商将为客户提供定制服务。
在Gartner调查研究的8家知名企业级EHR提供商当中,没有一家使用真正的SaaS模式，它们提供的全是托管服务。
选择SaaS模式的医疗服务机构通常要付一笔前期启动费，然后每月按医生数量支付订购费。据Handler称，“一条适用的经验法则是医疗机构为托管型EHR系统支付的费用为平均每个医生不超过500美元。实际上最后支付的费用可能低得多，这取决于提供商拿下单子的急迫性。”
IDC公司的Hanover说：“大型提供商在贷款方式上提供更多的选择。”例如通用电气医疗集团动用其资产高达50亿美元的姊妹部门——通用电气资本公司，提供一揽子贷款方案。像Greenway Medical Technologies这类较小的提供商可能会提供更个性化的服务，但需要借助第三方借贷合作伙伴来提供贷款方案。
通用电气医疗集团IT事业部副总裁兼总经理Jim Corrigan表示，他们将按医生数量进行收费，具体视服务级别协议的条款而定；服务条款涵盖多个方面的内容：诊所管理、连接到实验室的能力、保险付款和计费系统。这样做的结果是：GE收取每个医生3000〜6000美元不等的前期费用，每月收取每个医生300〜600美元不等的费用。Corrigan说：“我们还会尝试推出SaaS模式，即提高每月费用，降低前期费用。”
SaaS隐忧
虽然SaaS模式具有启动、运营和维护成本较低的优点，很诱人。然而问题不容忽视。
Bell说：“基于SaaS的EHR系统缺乏移植性。一旦提供商倒闭，或者当健康档案从一个EHR系统迁移到另一个EHR系统时，数据从现有系统迁移到其他系统将可能遇到问题。”Bell还提醒，许多用户没有考虑到SaaS EHR方案存在隐性的前期成本，比如包括安装相应网络、确保新软件与现有的诊所管理系统兼容的成本。所有这些成本都必须考虑进来。
譬如：纽约州的哥伦比亚纪念医院，它位于乡村地区，很难获得足够的带宽。这家医院的大多数远程诊所都使用部分T1线路或DSL虚拟专用网，下载速度和上传速度分别只有1.5Kbps和512Kbps。但是，医院需要768Kbps的双向传输能力，才能处理EHR系统带来的额外数据流量。所以，哥伦比亚纪念医院必须升级宽带网络，他们拉了一条万兆光缆线路。此外，再加上安装无线网络、服务器从Windows 2000升级到Windows XP，这些都导致意外成本的产生。
哥伦比亚纪念医院的网络管理员Michael LaForge表示，他们曾考虑使用SaaS方案，但董事会认为需要自己掌控信息、硬件和软件，代价就是成本高。LaForge没有表明这个项目具体花了多少钱，只是说造价高达数百万美元。“到最后，我们对于成本都感到有些惊讶。不但启动成本很高，还有日常成本，加之26个诊所和远程站点，成本一下子就上去了。”LaForge表示，医院不但要算上每月的许可费，还需支付平板电脑、笔记本电脑、智能手机、扫描仪、甚至传真线路等方面的维护和支持费用。
虚拟化给力EHR
哥伦比亚纪念医院的CIO Cathy Crowley主动表示，愿意将其数据中心对外共享，即便是与其没有隶属关系的诊所。哥伦比亚纪念医院因此获得了该州下拨的一大笔专款，帮助支付EHR部署成本。按照纽约州的HEAL New York专项拨款计划，这家有190个床位的医院能够提供虚拟化云计算网络，可以为26家诊所的200名临床医生提供服务。该医院排了一份相当紧凑的时间表，赶在六个月内完成实施EHR系统的工作，因为按专项拨款的要求必须如期交付。
为了节省资金、避免服务器散乱，同时集中管理系统，这家医院选用了VMware虚拟化服务器环境。医院还选择了Stratus Medical Grade ftServer和ftScalable Storage作为云基础设施的核心部分，确保所需的正常运行时间，为众多医师诊所提供服务。Crowley说：“要是我们不采用服务器虚拟化和另外一些技术，最后的成本会更高。不过即使那样，成本还是超出了预期。”这家医院有四个虚拟化服务器和一台物理服务器用于vCenter环境，光硬件费就要花几十万美元。
非附属诊所有自己的独立数据库版本，但它们都根据成本分摊模式向这家医院支付服务费。LaForge说：“从这个角度来看，这对它们来说就是一种SaaS模式。”
在一些情况下，拥有庞大IT部门的区域医院选择了扩建自己的数据中心基础设施，以便服务于所在地区的附属和非附属医院。正如IDC的Hanover所说，“IT常常不是小诊所的一项核心能力，小型诊所也不大可能长期留得住优秀的IT人员。”
匹兹堡医疗中心（UPMC）的系统就是共享EHR服务方面的一个典例。UPMC是一家年收入80亿美元的综合跨国医疗企业，它也是全美居于领先地位的非盈利性医疗系统之一。实际上，UPMC运行一个私有云系统。所有医疗、财务和行政管理应用软件都在共享环境里面运行。
UPMC的IT副总裁Paul Sikora表示，他的医院与该地区的另外27家医院共享其数据中心，包括匹兹堡儿童医院——这家医院决定在UPMC数据中心的独立服务器上运行其EHR应用软件。2009年，医疗信息和管理系统学会（HIMSS）将“HIMSS Analytics Stage 7”这个奖项授予匹兹堡儿童医院，表彰这家医院拥有一个先进的病人档案环境。Sikora说：“这家医院能取得这个成绩，一个原因就是它没有为基础设施操心。”
UPMC在2010年获得了“HIMSS Analytics Stage 7”奖项。5年前，UPMC就开始将其过时的数据中心基础设施推倒重来，耗资数百万美元。IDC评估UPMC后得出结论：这家医院避免了大笔支出，要是继续使用原有的基础设施，就需要8000万美元的支出。Sikora表示，除了节省8000万美元的成本外，他还不需要为了跟上服务器增多的步伐而新建一个造价8500万美元的数据中心。他说：“能够节省这一切费用，是因为我们部署了虚拟化技术，UPMC虚拟化环境的运行成本仅为原有数据中心的五分之一。”
UPMC在22台物理服务器上运行1300个Windows虚拟机，这样它只要通过敲击键盘，就可以在数小时内为它所服务的医院增添计算容量，而不是另外扩建基础设施。I/O负载与环境中最具成本效益的计算机服务相匹配。UPMC不仅用VMware对服务器进行了虚拟化设置，还利用IBM的存储区域网（SAN）卷控制器设备对存储系统进行了虚拟化，IBM的这个设备放在存储阵列前面，让存储阵列在应用服务器看来就如同单一可用容量池。他说：“如果你的所有企业系统都在一个标准化环境中，就能以不同方式来管理它。你会开始看到负载特性，然后确定可以把这部分数据放到成本较低的第3层存储介质上。”
UPMC的197名IT人员负责支持4000名医生的工作。2005年开始整合及升级数据中心，当时政府根本还未确定“有意义使用”方面的要求。Sikora表示，光从基础设施的角度来看，EHR背后的技术“极其复杂”。如果一家中型医院开始着手EHR项目，单单让新的基础设施运作起来就可能占用一半以上的精力。他说：“而这恰恰阻碍了医院建立健康档案的能力。我们部署的系统极具扩展性，众多社区医院可以在我们的环境中进行信息共享。我认为，要是政府能资助某种区域性的数据中心，多支付一些费用也不失为更明智之举。”
链接
选择通过两项认证的EHR
按政府规定，“有意义使用”分三个阶段。现在部署EHR的医生和医院按照第一阶段指导方针进行部署。第二阶段和第三阶段准则分别定于2013年和2015年生效，而最终规定大概会在生效前一年颁布。
第一阶段的标准侧重于改善病人护理的质量、安全、效率和协调，并侧重于减少医疗不平等。它们还要求对病人的健康信息在隐私性和安全性方面给予足够的保护。第一阶段必须满足25个目标，其中包括：至少80%的医生医嘱和10%的医院医嘱必须使用计算机化医嘱录入（CPOE）系统；必须实现药物和过敏的实时提醒；临床医生所开的处方中至少75%必须通过电子方式传送到药房。
Bell表示，大多数人一想到EHR，就会想到软件，但整套系统还需要硬件、运营和技术等方面的支持，还有宽带网络及无线连接。成功部署EHR还要得到工作人员的接受和使用，Bell说：“信不信由你，现在还有许多人是不习惯打字的。”
Handler说：“如何让系统运行起来？如果这是一家连锁医院，该如何将系统部署到旗下的所有医院，并确保系统的各个部分有条不紊地部署？从某些方面来看，解决问题的关键不在技术和软硬件上，而在文化、治理和管理上。”
ONC借助CCHIT对EHR进行测试和认证，CCHIT还有权对自主开发的EHR系统进行认证。到目前为止，CCHIT对66个EHR产品进行了认证，认证产品的先进程度不一。Bell表示，要是某家医院扩建自己的基础设施，把各软件模块组合起来，该医院就能远程访问服务器，并与管理员一起提供专门针对该系统的认证。
CCHIT提供两项EHR认证：一项是CCHIT 2011 Ambulatory认证，这类EHR系统拥有最先进的安全功能、集成组件以及最可靠的病人护理能力；一项是ONC-ATCB，只能证实EHR系统能够帮助医护人员满足“有意义使用” 的要求。
通过后一项认证的系统将帮助医生和医院获得政府的奖励资金，却可能无法提供医患互动方面的一整套功能。而更有可能的是，那些用于计费、病人安排、影像归档及其他任务的各个模块无法彼此联系，这意味着必须通过不同的接口加以管理。
领域化业务构件描述体系及部署方法 篇4
1 业务构件描述
各个行业的企业总有一些核心业务,长久保持不变,新时期的新业务基本上都是围绕核心业务展开。但是业务的扩展和IT技术的发展始终是一对矛盾的存在,如何重用原有的技术成果去描述常变的业务需求,是当前软件开发行业内所关心的话题。
就企业信息化领域而言,企业和业务包含几个重要要素:业务术语、业务流程、业务活动、业务表单、组织机构等。这些要素相互作用实现企业特定的目标。业务术语代表着领域化数据,是业务的数据来源;业务流程和业务活动代表着用户与系统之间有规律地交互,是业务的语义体现;业务表单代表着用户同数据之间的交互,是业务的交互接口。三者之间互相作用,完成一项特定的业务需求。至于组织机构,可以认为是业务术语的一个子集。
所以提出一套方法:对业务进行抽象分解,抽取出最核心的部分并使用统一的格式去描述,再把他们封装成基础颗粒(构件),定义向外提供的服务,在上述基础工作之上,就可以定义出具有不同功能甚至不同版本的构件,将它们部署在一个架构之上去运作完成指定的业务,从而应对当前企业信息化领域的业务需求挑战。在企业信息化领域对企业业务进行层次化划分为数据模块,流程模块,用户界面3部分。
1.1 业务数据
数据模块是企业信息化领域数据特征的抽象,用于描述一组数据的概念和定义。使用概念建模的方法:现实世界中存在各种概念,本质不同的属性集合,换言之不同的属性,依据一定规律或规则,形成的集合是概念。数据是企业信息内容积累的重点,建立业务数据库对业务概念重用有着重要作用。
业务数据作为业务构件的底层支撑部件,需要提供服务来供构件其他部分或者其他构件去调用。对其进行逻辑封装,将操作封装成业务服务发布出去。另一方面,通过映射逻辑操作,将概念和所属属性映射至持久层中去,这也是数据持久化的途径。
业务数据用于描述企业业务里包含的丰富的概念知识,它是整个业务模型的语义基础,可以规范和约束业务所处理的数据。为数据赋予语义,不仅可以促进企业知识的重用和共享,还可为企业数据交换和集成带来好处。
1.2 业务流程
企业信息化核心职责是企业集成化、协同一体化,关键是实现商务流程系统和商务数据的互相协同。企业信息化领域的施工模块划分,一般以一项完整的流程作为划分的依据,因为它包含最小的独立可执行业务信息。并且在实际开发中,业务数据一般相对稳定,业务流程则是随需求常变的,故将业务流程当作构件中的一部分。
业务流程就是业务页面在不同用户之间流转。业务流程分为:业务活动,业务动作和业务规则,它建立在业务数据承载基础之上。
业务活动是业务流程的一个环节,每一个业务流程是通过处理一个个业务活动来展开的。它是状态的集合,另一方面也是用户访问的基本单位。利用业务活动这个载体,通过其传递、流转体现了企业协同交互功能。
业务功能,也可以理解为业务动作。它被业务活动引用去实现特定的业务操作,换言之它解决了业务流程中做什么和怎么做的问题。在开展业务活动时,参与者根据自己的权限进行受限范围内的操作。
业务规则,表示业务流程与业务活动中的丰富规则,它使流程在业务需求下恰当运行。业务流程有启动规则、流程合并规则。通过启动规则,可以确定流程在什么情况下启动以及如何启动。流程合并规则规定多个流程实例如何并行处理,方便大量流程的共同处理。业务活动之间通过连接弧、逻辑环节、条件环节等连接,这样规定了各项活动之间的先后关系和逻辑关系。最后每个业务活动上可以制定执行规则,转发规则,回退规则,时间规则等。
1.3 用户界面
用户界面和业务两部分之间完全独立的,他们之间通过服务接口交互。用户界面通过技术框架去实现同表单数据、业务流程之间的松耦合。它分为4部分:数据+格式+动作+规则。
数据部分定义了包含在表单中的数据,并规定了用户提交时如何处理数据。数据可以是数据模块中的概念,流程上下文数据,静态数据等;格式指数据如何在表单中布局以及采用什么构件来表现数据等。现在广泛使用的是xbl(界面构件),xforms(界面具体展现)等技术规范;在用户界面中,可以定义各种业务动作,也可以调用数据模块或者流程模块中定义的业务动作,采用事件驱动架构进行业务动作的响应;数据规则的检查,包括计算、约束、必须、只读等;最后还需要胶水层代码以实现一些简单业务逻辑。
2 业务构件拼接组合
类似于对家具的各个零件部分进行组合、拆装来进行家具的搭建。下面对业务构件的组合以及拼接部署进行讨论。
2.1 业务构件封装
能否对软件开发进行更为有效的分工,降低程序员重复单件工作的成本,是衡量软件技术能否在复用性上取得突破的根本准则。因此提出,用户界面、业务流程、业务数据以及彼此之间提供的动作服务的集合,称之为业务宏构件,如图3所示。
业务数据提供数据库表的映射服务;业务流程提供流程服务供流程引擎调用操作;用户界面提供界面服务供用户访问及交互。业务流程为语义执行核心,一方面通过技术框架中的容器同业务数据绑定,另一方面通过REST服务同用户界面发生关联。3部分均支持事件驱动框架提供业务服务供其他宏构件调用导入。最后提供系统管理服务,对宏构件进行部署、注册、注销等管理操作。注意一个业务构件可以由多个业务数据,多个业务流程,多个用户界面组成。
2.2 构件服务接口描述
由图3中可以看出,构件提供出的服务大致分为3类:界面服务,数据逻辑服务,业务动作服务。服务的接口规范基于WSDL(Web Service Description Language),而且也提供Java接口,这样使用业务构件的客户端可以选择使用WSDL接口或Java接口。服务接口类型具体采用哪种调用关系则主要是考虑性能、接口复杂度、耦合性等问题:不同构件之间可以通过 REST 服务进行调用;一个业务构件内部,业务构件和公共模块之间的调用实现 API 调用。
由于涉及到业务构件内外的调用,因此需要制定专门的绑定信息。这些绑定信息包括了目标服务或者源服务的调用方式,位置信息,调用的方法等。常用绑定方法有JMS绑定和Web Service绑定等。
2.3 构件的可配置化部署
文献[4]中提出了一套基于构件的软件配置管理系统模型。使用XML语言进行构件之间的配置描述,需要描述的部分大概有:构件的类库组成;描述构件暴露的服务;构件域描述,描述系统可用节点,互联接信息和桥接信息;逻辑构件映射成物理构件服务过程等。构件调用关系如果想实现自动绑定(Auto-wiring),还需要在标签中加入Autowire属性等标签。
系统架构彻底可配置化,要求框架本身构件也必须像业务构件一样可定制、可配置。这就需要一个微内核配置文件。框架本身构件也是靠配置这个微内核的配置文件达到组合使用或更换个别零件。
2.4 构件架构的实现
依照前述讨论内容,现假设存在多个业务功能不同的构件,为使他们彼此之间协同工作组成一个完整的信息系统,文献[5]提出了一个可拓展的集成式构件描述框架。这里结合CCM(Corba Component Model)标准和企业信息化领域的业务问题,提出一套构件框架模型,如图4所示。
业务服务总线是体系架构的核心,它负责缓存数据,统一数据格式,进行服务的引用调度,启动相应流程引擎,页面引擎等核心功能。
将跟每一个业务构件紧密相关的部分单独作为一个构件,即公共服务构件。业务构件和公共构件使用一个数据库,通过相关标准实现整合。公共服务构件包含组织管理、菜单管理、流程管理、系统管理、报表打印等。业务构件则由用户定制并部署至平台架构中,类似插件一样进行工作。
例如对会议管理部分进行分析。按照流程进行划分,可分为会议通知,会议记录,会议结果处理3个具有独立流程的部分,所以每部分作为一个宏构件进行设计。以会议通知为例分析,要求发起人填写会议信息并分发至参会人员并得到回执。流程包括3个环节:创建会议信息、分发通知、发送回执。业务流程从流程库中选择简单无分支流程类型,对环节进行命名和简单删减以符合流程要求,业务数据从本体库中选取会议本体,可依据企业需求选择所需子集,业务页面选择主表流式布局。接下来进行3部分之间的连接配置以及特色业务服务实现。主要包括:(1)页面技术构件同数据源属性之间的绑定。(2)页面业务服务实现流程各个环节执行者、分派模式等规则设定。(3)同组织机构构件交互的规则设定。(4)部署执行配置。最后通过Osgi技术将3部分资源以及配置信息打包封装,植入构架中运行。
以上为会议通知这一宏构件制造过程,若流程需求发生变化,只需对其流程环节进行轻微修改;若表单需求发生变化,只需对用户界面布局进行改变;若业务需求发生变化,只需对响应业务服务进行修改编码。三者之间彼此耦合度低,影响不大。这样就能将维护局限在宏构件中,甚至还可加入版本机制,增强复用度。
3 结束语
在对当今企业信息化领域分析的基础上,提出宏构件概念,借鉴CCM标准,对构件的拼接部署方法进行了讨论,提出了基于宏构件的业务架构平台,为企业信息化领域构件化开发提供一种可行的解决方法。
参考文献
[1]ZHU S Y,QIAN L Q,SU W M.Software engineering technol-ogy conspectus[M].Beijing:Science Press,2002.
[2]徐玮,尹宝林,李昭原.企业信息系统业务构件设计研究[J].软件学报,2003(7):2-3.
[3]孟凡超,战德臣,徐晓飞.基于领域业务模型的可重用构件设计方法[J].计算机集成制造系统,2006(12):98-101.
[4]张路,谢冰,梅宏,等.基于构件的软件配置管理技术研究[J].电子学报,2001,29(1):267-276.
业务部署 篇5
在国家电网公司初步建成集中式数据中心的背景下，针对公司各已建和在建应用系统逐步向集中部署模式迁移的现状，亟需对新环境下集中部署业务系统统一监控技术进行研究。现有的监控方式存在监控架构异构、监控模式不完善、监控指标与评价体系不一致等问题，难以适应集中部署业务系统对监控的需求。集中部署的业务系统用户规模大，各类业务应用的特点明显，实现的技术路线区别较大，这些特有的复杂度、差异度、专业度将为统一监控的实现带来极大的挑战。统一监控的关键在于建立完善的监控模式、统一的业务系统指标集与自下而上的告警机制，保障公司信息化建设平稳、有序、规范的向集中部署模式转变，确保业务系统安全稳定运行。
1 研究思路
1.1 监控模式
对集中部署业务系统的统一监控以监控系统业务运行为主线，并对支撑其的中间件、数据库、网络、虚拟资源、主机、机房环境等资源进行监控。主要以图形拓扑方式进行信息展示，并提供实时查询与统一告警。
业务运行监控包括对集中部署业务系统业务指标的实时收集和业务流程的检测。业务流程的检测分为主动探测和被动抓包两种方式。即对集中部署业务系统进行虚拟用户的主动模拟业务探测；对业务系统的通道通过镜像等方式被动收集数据包进行分析，来判断业务流的正常。
资源监控是监控与集中部署业务系统相关联的中间件、数据库、服务器、网络设备等资源。对这些IT基础资源进行独立的监控，当某一层出现问题时，其上一次层肯定是要受到关联，原因的判断主要根据告警发生的先后顺序，来判断故障源头。如当数据库链接超过阈值时，其会占用大量内存，使内存占用率超过安全阈值。进而使业务系统响应速度变慢，直至瘫痪。
通过对业务运行监控与资源监控的深入分析与挖掘，梳理出能够全面反映集中部署业务系统运行状况的监控指标，建立统一的指标集与对应的评价体系，从而实现对集中部署业务系统的统一监控。
1.2 技术路线
本文通过对集中部署业务系统进行基于SNMP标准协议监控的研究，为集中部署业务系统统一监控技术路线打下基础。
简单网络管理协议（Simple Network Management Protocol,SNMP），由一系列协议组和规范组成，包含一个应用层协议（Application Layer Protocol）、数据库模型（Database Schema）和一组资源对象。该协议能够支持网络管理系统，用以监测连接到网络上的软硬件平台。
基于SNMP实现的网络管理系统一般由以下几个部分组成：管理基站（SNMP Manager），管理代理（SNMP Agent），管理信息库（Management Information Base,MIB）和管理协议。管理基站作为管理端，是运维人员进行网络管理的用户接口，它具有向被管对象发送操作指令以及接收被管对象反馈信息的作用；管理代理（Management Agent）有两种方式，一种是网络设备，如主机，网桥，路由器和集线器等；一种是软件服务，如Net-SNMP等。这些设备或服务上的管理代理（Management Agent）都能够接收来自管理端发送的指令信息，并且这些代理的状态也能够被管理基站监视。管理代理（Management Agent）响应管理端的指令并进行相应的操作，也可以在没有请求的情况下向管理端发送信息；MIB是所有被管理对象的数据库，代表网络中所有可以管理的资源，如设备、服务等。每个MIB对象对应一个数据变量，每个数据变量则代表被管对象的某一个方面的信息，如主机内存占用率、CPU使用率等；管理协议，即SNMP。它的基本功能是：取得（Get），设置（Set）和代理者主动向管理站通报重要事件（Trap）。
本文所述的对于集中部署业务系统SNMP的监控系统中，监控系统本身（包含其所在设备）具有向管理代理收发指令信息的功能，相当于管理基站。围绕各集中部署业务系统，有许多被管对象需要被监控，包括数据库、中间件等软件，还有主机、路由器、交换机等硬件，每个被管对象的信息以层次的方式组合，最终分解成数据变量固化于管理信息库中，管理信息库为每个对象定义对象标识符（OID）作为惟一标识。每个被管对象上都运行着管理代理（SNMP Agent），作为与管理端通信的媒介。本文设计的管理代理实际上是一种SNMP服务，它不直接部署在业务系统，即被管对象上，也不是业务系统的一个组件。这个服务只负责维护业务系统所有指标数据的OID、获取方式，这种获取方式可能是一个数据库查询SQL或者一个可以调用的API接口等，以及处理来自客户端的SNMP请求。
2 指标模型
集中部署业务系统统一监控的基础和关键是集中部署业务系统的监控指标集。要实现对不同业务系统的统一监控，首要任务是建立相对统一的指标集，并在指标集的基础上建立科学的评价体系，最终通过评价体系掌握各集中部署业务系统的真实情况，实现统一监控。
指标集的建立首先根据集中部署业务系统的实际情况，参照国网前期的运维经验与现实需要，开发出能够准确、充分地反映集中部署业务系统情况的指标，再参考国内外成熟系统的先进案例完善提升，形成业务系统运行指标与应用指标两大类型指标的指标集。
业务系统运行指标主要反映系统本身的运行状况及关联资源如服务器、数据库、中间件等的状态，（视运维工作需要扩展）如表1所示。
业务系统应用指标主要反映集中部署业务系统业务水平情况，由于不同的业务系统有着各自特有的核心业务逻辑和业务流程，所以应用指标也不相同，以国家电网公司集中部署业务系统电子商务平台为例，其应用指标（视运维工作需要扩展）如表2所示。
之后本文针对指标集建立了一套评价体系，为运行指标模块和应用指标模块分别赋予权重（可配置），根据业务系统的实际情况，指标集中的每个指标参照评价标准会得到相应的分数（满分10分），最后汇总出一个总分，这个总分即为反映该集中部署业务系统总体情况的重要依据之一。
3 MIB设计
要实现基于SNMP对集中部署业务系统的监控，首先需要完成MIB的定义，将集中部署业务系统需要监控的对象信息以变量的形式固化到管理信息库中，才能被管理代理识别并被管理端访问。
根据管理信息库的对象命名树结构，企业的管理信息库对象为：
将国家国家电网公司的私有管理信息库（Management Information Base,MIB）的根节点定义在企业管理信息库对象下：
在此根节点下扩展所有集中部署业务系统的监控信息，形成国家电网公司集中部署业务系统监控的树形结构。
首先根据国家电网公司的业务分类定义业务节点，再在此业务节点下定义监控节点，形成对于业务监控的根节点：
对于集中部署业务系统的监控，按照其所属的业务分类，在业务监控根节点下分层定义，以国家电网公司物资管理业务为例：
其中：节点.mat代表物资管理业务；节点.elc代表物资管理业务下的电子商务平台（系统）。
电子商务平台的运行指标与应用指标就定义在系统节点的叶节点上，以电子商务平台的运行指标“健康运行时长”为例，其节点定义如下：
至此，就完成了集中部署业务系统监控指标在管理信息库中的定义，而且该管理信息库易维护，方便其他业务系统及监控指标的扩展。
4 SNMP Agent设计
集中部署业务系统监控的管理代理（SNMP Agent）作为管理端与被管对象的媒介，依靠SNMP实现信息通信，架构图如图2所示。
该代理的功能模块（可扩展）设计如表3所示。
5 告警设计
科学、完备的告警机制可以为运维人员日常工作提供规范、有效的告警信息，辅助运维人员进行故障判断，缩短故障解决时间，减轻运维压力与被动性，为信息运维提供有力技术支撑。告警设计的关键在于建立告警模型，本文通过对集中部署业务系统及其相关联IT资源的梳理，根据IT资源的层级架构（见图1的监控层级图）建立集中部署业务系统层级告警模型，自下而上分为动力环境告警层、硬件/网络（包括虚拟环境）告警层、软件/服务告警层、业务系统告警层，以拓扑形式建立层级关系，故障发生时，系统按时间顺序发出告警。引入智能判断机制，根据告警级别、告警层级对故障进行智能判断，并生成关联分析报告，供运维人员分析参考。
一般的告警机制属于“事后告警”，告警发出时，故障已经发生，失去防患于未然的意义。对于集中部署业务系统的告警设计，除常规的告警设计外，更加侧重于对于故障的预防，加入预警的设计。预警设计的关键在于指标阈值的估算，阈值越精确，预警的价值也越大。本文基于国家电网公司多年的历史性能数据，根据平均值计算出资源性能指标数据的趋势曲线，当趋势指标数据超出阈值时，即存在发生告警的可能。提供灵活配置告警类别、严重级别、告警阈值的告警规则，系统依据用户配置的告警规则提供包括短信、邮件、语音等多种方式的告警服务功能，通过告警管理降低管理被动性，逐步实现无人值守的运维管理。
6 结语
本文从国家电网公司集中部署业务系统的监控需求出发，开展对集中部署业务系统统一监控技术的研究。首先根据业务系统的实际情况，梳理出能够全面反映业务系统运行状况的监控指标，建立统一的指标集与评分体系；然后采用基于SNMP协议的管理代理方式完成MIB与SNMP Agent设计，实现业务指标的固化；之后通过告警模型的设计支撑业务系统的运维管理；最终克服传统监控方式存在的不足，实现了对集中部署业务系统的统一监控。目前，本文所述的统一监控技术已应用于国家电网公司集中式数据中心，对于已迁移的集中部署业务系统已实现指标集的固化，评价模型也已用于日常考核，对于集中部署业务系统的统一监控已初见成效。随着更多的业务系统完成迁移，对于集中部署业务系统统一监控的研究成果将对提高运维人员的效率，提升集中部署业务系统的实用化水平与应用水平，降低管理成本发挥越来越重要的作用。
参考文献
[1]葛君伟.云计算环境下的资源监测模型研究[J].计算机工程,2011(11):31-33.
[2]魏钢,赵杰.基于SNMP的集群服务器状态监视系统设计[J].网络安全技术与应用,2011(1):25-28.
[3]张彤,吴世荣.基于SNMP计算机网络流量监控系统研究[J].计算机技术与发展,2011(1):88-91
[4]张登银,陈玮,任勋益,等.基于SNMP的MIB库转化成C文件的实现[J].计算机技术与发展,2011(9):6-9.
[5]朱平尧.基于SNMP协议的CMTS/CM综合网管系统的设计与实现[J].中国有线电视,2011(z1):6-15.
业务部署 篇6
中国电信IMS 8省试点已经结束, 几位受访电信运营商人士均向记者表示, 现在正在准备IMS集采前的一系列准备工作, 预计将在今年年底进行部署, 继中国移动之后, 中国电信也将开启IMS商用局。
中国移动已经部署了大量IMS网络, 主要将IMS用于补足其固网短板;中国电信现在有CDMA网络为移动用户提供服务, 软交换和交换机网络为固网用户提供服务, 其网络具有相对复杂性。鉴于IMS对于中国电信带来的价值是多方面的, 其在试点之中也将重点放在了验证IMS为现网带来的业务能力提升、IMS网络演进、IMS能力开放等内容。
IMS性能背后的难题
“IMS就是一个多媒体的业务应用, 无论是固网, 还是移动网都能使用这个业务, IMS的特殊性则在于要对用户进行管理, 要开发适合IMS的业务, 做到不同业务的等级划分。”中国电信上海研究院的一位专家如是表示, 而对于中国电信部署IMS所面临的挑战也正是存在于IMS的这些性能的相关方面。
中国电信现网中包括大量的现网, 而且有多样化的接入方式, 在IMS部署过程中如何承载现有业务是中国电信面临的首要问题, 华为、中兴等厂商纷纷表示。而对于中国电信而言, 初期的试点工作主要也放在了IMS性能是否能够充分发挥上面。另外在网络方面, QoS的保障措施尚未完善, 无法根据业务的优先级灵活调度。
IMS是建立在IP网络的基础之上的, 运行的仍是数据业务, IMS通过统一的IP网络进行承载, 对网络的要求更高。既要保证网络的电信级标准, 又要确保在不同的IP地址模式上进行承载。
IMS作为一个业务应用平台, 其更多的作用仍体现在多媒体应用及各类终端的接入上面。上海电信负责IMS试点的一位专家告诉记者, 现在运营商需要迫切解决的问题就在于缺少种类丰富的终端产品, 这对于运营商下一步发展新型的业务模式非常重要, 也是运营商关注的重心。
另外上述中国电信上海研究院专家同时强调了IMS配套设施的重要性, 当前设备商所提供的配套措施尚不完善, 突出表现在网络管理和计费方面, 需要厂商有针对性的对此开发。
难点不在核心层
“从中国电信试点情况来看, IMS的网络在协议、标准等方面已经成熟, 问题凸显在业务层面。”
亚信联创的一位常驻中国移动的专家表示, IMS对于核心网来说, 不过就是多增加了一个业务, 增加负荷, 而网络层面也只是IP地址的使用, 现在中国移动承载网80%的业务仍是软交换, 有充足的带宽和承载能力, 没有部署QoS的必要。而浙江移动的程路同时表示, 浙江移动始终保持IP承载网络的宽带利用率不超过30%, 尽可能地保障IMS的业务质量。
上述上海电信的专家也明确表示, 通过在上海的IMS试点, IMS的网络运行稳定, 可以有效支持多种固网、移动接入模式。
另外, 从各厂商所提供的解决方案来看, 运营商在核心网层面的挑战, 厂商已有较为成熟的应对方案。华为相关专家表示, 在中国电信的这次试点中, 华为配合福建泉州电信采用IMS进行PSTN网改, 通过充分的验证和实践表明, 基于IMS进行话音网络改造是可行的。目前泉州电信已完成上千用户的割接, 网络运行稳定, 用户反映良好。
前述中国电信上海研究院专家透露, 当前中国电信一直在积极研究业务融合的模式, 最近一直在提的ISAG (综合业务接入网关) , 也正是业务融合的一个必要设备。
设备商更是将业务创新作为其IMS解决方案的核心层面进行展示。华为专家表示, 华为与广东电信、广东研究院进行合作, 在东莞开展彩色e家的商用试点, 目前已发展上千用户。同时, 后续华为将与广东电信保持合作, 促使彩e达到规模商用。
上海贝尔在与上海电信、山东电信的合作过程中, 依据各地网络特点, 开拓了多种新型业务模式, 包括视频共享、视频号百、多媒体彩铃、业务能力开放等模式。
link
固网运营商IMS部署案例
德国电信匈牙利子网T-COM是匈牙利最大固网运营商, 遇到单纯语音服务无法满足用户需求, 固定用户离网率高的问题, 其现网部分交换机也将停止维护。目前T-COM已成功将现网部分交换机的PSTN用户全部割接到IMS+MSAN网络, 在线用户总量取得巨大突破。
业务部署 篇7
1 NAT444技术简介
NAT444作为缓解IPV4地址枯竭的一种有效方案, 其主要思想是用户拨号上网获取私网IP地址, 由运营商部署运营级地址转换设备CGN (运营级网络地址转换设备) , 同时与用户侧的NAT (网络地址转换) 组成两级地址转换, 形成三块地址空间, 即用户侧私有地址、用户拨号获取的运营商分配的私有地址、公网地址。NAT444方案可以提高IPv4地址的复用率, 缓解地址枯竭问题, 而且便于部署, 只需在汇聚层或者核心层增加CGN设备即可, 无需进行较大规模的设备替换。从用户感知度、技术成熟度和部署难易度等方面考虑, NAT444是目前比较好的方案。
2 NAT444下WLAN业务存在的问题
目前的WLAN业务的认证流程图如图1所示, 其主要步骤如下。
1) BAS (宽带接入服务器) 重定向用户的http请求到portal;
2) portal通过与BAS的接口发送用户名、密码到BAS;
3) BAS发送认证包到RADIUS (远程认证拨号用户服务) ;
4) RADIUS返回认证结果给BAS;
5) BAS返回结果给portal, portal展示认证结果给用户;
6) BAS允许或禁止用户访问互联网。
在NAT444环境下, 上述流程无法正常运行, 主要问题在步骤3上。在目前的WLANportal环境下, 用户获取的是公网地址, WLANportal上保存BRAS (宽带接入服务器) 设备和公网地址池的映射关系 (BRAS地址, 地址池起始IP, 地址池结束IP) , 因此WLANportal根据来访的用户公网IP就能直接定位用户是从哪台BRAS设备接入的, 将用户在portal网页上输入的用户名和密码通过和BRAS的接口发送给BRAS设备。
在NAT444环境下, 用户获取的是私网IP, 用户访问portal页面的时候, WLAN portal获取到的是该私网IP经过NAT以后的公网地址。此时WLAN portal将无法知晓用户究竟是从哪台BRAS接入的, 后续portal和BRAS交互的流程也就无法运行。
3 NAT444场景下WLAN业务部署方案
为了解决该问题, 我们提出在认证全流程定义一个属性携带用户私网IP的解决方案, 该属性定义为wlanuserip, 改进后全流程如图2所示。
此时详细认证流程如下:
(1) 用户在AP (接入点) 下获取私网IP后, 发起任意http请求;
(2) 设备重定向, 同时携带wlanuserip参数 (即用户无线网卡获取的私网IP) , BRAS设备截获未认证用户的http请求, 返回重定向地址;
(3) 用户访问portal, 携带wlanuserip参数值。用户使用重定向地址访问portal时, 必须携带wlanuserip, 否则或导致认证不成功;
(4) portal获取wlanuserip, 并推送统一认证页面给用户;
(5) 用户输入的用户名、密码以及其他参数发送到portal, 发起认证;
(6) portal获取到用户的认证信息后, 使用wlanuserip作为用户认证的IP, 组织好认证报文向设备发起认证请求;
(7) 设备向AAA (认证、授权和计费) 发起认证请求;
(8) AAA回应认证结果给设备;
(9) 设备回应认证结果给portal;
(10) portal展示认证结果页面给用户, 认证成功提供下线按钮或连接, 携带wlanuserip参数值。
4 结束语
原有城域网WLAN业务分配的是公网IPv4地址, 随着Wl AN业务快速发展, 公网IPv4地址占用率快速增长。随着公有IPv4地址即将枯竭, IPV6技术还未能成熟商用, NAT444技术是公认的过渡技术之一。
业务部署 篇8
1 xPON承载IPTV组播业务方式概述
(1) 组播实现方式
在xPON系统中, IPTV业务包括IGMP (Interne Group Management Protocol) 协议报文处理、基于OAM组播控制报文的控制管理以及下行组播业务流转发。OLT通过广播信道以单拷贝广播 (Single Copy Broadcast, SCB) 方式将组播内容分发给所有ONU;PON (Passive Optica Network, 无源光网络) 系统支持并工作于如下两种组播控制方式:IGMP snooping方式或xPON系统特有的动态可控组播方式。
(2) IGMP Snooping方式
IGMP Snooping方式下, OLT执行IGMP Proxy, ONU执行IGMP Snooping功能实现对组播成员的管理。通过标准的IGMP协议实现动态的组成员管理, 由IGMP Report/Leave和query消息实现组播组成员的动态加入/退出和维持。该方式下xPON仅实现简单用户组播权限控制, 组播业务权限控制由IPTV业务平台实现。
(3) 动态可控组播控制
动态可控组播方式是OLT基于IGMP控制报文携带的用户标识信息进行用户鉴权, 并通过扩展OAM消息控制ONU对组播数据报文的转发管理。当PON系统下的用户申请特定组播频道时, 会向上发送IGMP Report报文。Report报文进入ONU的以太网用户口时, 打上标识该端口的VLAN ID。该VID的值为接收到该IGMP控制报文的以太网UNI端口号。
OLT接收到IGMP Report报文后, 根据端口 (用户) 标识、Report报文的组播IP地址以及源IP地址查询该端口 (用户) 对该频道的访问权限及其参数。并根据查询结果进行相应的转发或丢弃。若业务流可以转发, 则PON系统进行正常的IGMP协议报文交互。
2 xPON承载IPTV组播业务转发流程和特点
(1) 组播业务转发基本流程
1) 点播节目使用单播通道 (点播VLAN) 。组播业务时用户 (机顶盒) 发出相应频道的IGMP加入报文, OLT将用户加入相应组播组, 组播流通过组播通道 (组播VLAN) 下发到机顶盒;
2) OLT定期发送通用组播查询包, 机顶盒接收并在超时前回复, 确保用户保持激活;
3) 用户切换频道时, 机顶盒向原组播组发出IGMP离开报文, 再向新组发出加入报文。
(2) PON承载组播业务的SCB分发机制
SCB是xPON特有用广播方式发送下行数据技术:OLT和ONU间单播和上行IGMP协议报文在单播VLAN中传送, 组播流和下行IMGP协议报文在组播VLAN中传送 (采用SCB) 。在转发组播业务时, 多个用户点播同一节目, OLT只发送一份媒体流拷贝进入SCB逻辑通道, 所有用户接收同份数据, 即一份业务带宽可为多个用户提供服务。对于高清视频业务来说, SCB技术带来的带宽节省十分明显。PON系统要求每个PON口下有惟一的SCB通道, 所有组播媒体流均在此通道中传输。若要相互隔离, 则使用不同的VID来标识和区分。
(3) PON承载组播业务性能和特点
1) OLT设备每秒处理IGMP协议报文的能力不小于32×PON接口数量×25%;
2) 在组播流已递送到ONU设备的情况下, 用户终端从发送IGMP请求报文到ONU设备开始向该用户终端发送组播数据报文的时间不超过100ms;
3) PON系统为有效利用带宽, 支持快速离开 (Fast Leave) 模式:该模式下终端从发送IGMP离开报文到ONU设备停止向该终端发送组播数据报文的时间不超过100ms;
4) PON系统为提高组播性能, 支持静态组播/预加入组播功能。
3 IPTV组播业务对xPON网络的影响
(1) 组播视频对接入速率的影响
视频业务 (组播) 在PON网络业务中对整体带宽影响最大:标清视频业务所需带宽3M, 高清视频业务所需带宽8M。组播在高峰时段集中度较高, 近似所有用户同时在线。因此对组播业务主要按节目数来评估带宽, 以标清业务100套、高清业务10套计算, 所需总带宽为380M, 因此视频业务 (尤其组播) 带宽需求可能占到xPON设备PON口侧带宽的35%左右。尤其在端口流量较大时, 组播业务对用户接入速率影响尤其明显。
(2) IPTV组播对设备处理能力的影响
分布式IGMP组播方式中IGMP协议报文需要网元提取处理, xPON系统可以选择适当IGMP工作模式、报文限速或者降低优先级方式, 保证在组播报文出现异常情况下对网元冲击有限, 并可对其他报文的正常响应和处理。
1) IGMP工作模式:OLT采用IGMP proxy方式, 减少处理的IGMP协议报文, 降低系统负荷。若部署透传方式, OLT关闭IGMP提包, 避免无效IGMP协议报文对CPU的冲击。
2) 报文限速:xPON系统对IGMP协议报文限速, 正常情况下组播协议报文有限, 所以限速对业务没有影响, 但可避免IGMP协议报文异常过多是导致的其他协议报文丢弃。
3) 业务优先级:从业务流量特性以及网络安全性角度考虑, 组播业务 (包括协议报文) 优先级不宜过高, 保证业务拥塞情况下高优先集业务可正常转发。
(3) IPTV组播对业务形态的影响
xPON承载的IPTV组播业务在网络流量上呈现较明显的非对称性:流量主要有下行媒体流构成, 协议报文流量相对很低, 即下行业务流量远大于上行业务流量。组播业务占总带宽占比很大, 所以组播业务的非对称性影响了xPON网络 (PON口) 业务流量的非对称性。
IPTV组播业务通过专用SCB通道下发, 由于SCB的下行方向性, 因此不支持上行组播媒体流。某些场景下存在的上行组播只能通过洪泛实现, 而洪泛报文对系统业务形态具有较大影响并受到严格限制。同时方向性也决定了不支持组播流在PON设备用户端口间的转发。
4 xPON承载组播部署的透传模式和分布模式
组播业务从部署形态上可以分为透传模式以及分布模式, 不同模式特点有较大差异。
(1) PON系统透传模式部署
该模式下, PON系统透传组播业务, 不涉及对组播业务的处理。该方式多存在于IPTV业务开展初期, 直接利用现网BRAS能力和传统上网业务模式。PON系统为组播业务配置普通VLAN通道, 并对IPTV端口的组播报文进行VLAN标记, 配置方式如下:
1) PUPV方式:按用户划分VLAN。该方式规划配置简单, 但业务区分和隔离能力弱。
2) PSPV方式:按业务划分VLAN, 所有用户组播业务共享同一VLAN。
3) PUPSPV方式:按用户业务划分VLAN, 每个用户的IPTV业务规划独立的VLAN。该方式业务隔离良好, 同时可定位业务用户, 但需要较多的VLAN资源和良好的资源规划。
对PUPV和PSPV方式, 出于业务用户定位需要, 一般会采用QINQ双层VLAN配置。同时由于组播业务不涉及用户间交互, 用户隔离可通过PON系统底层实现。
(2) 分布式IGMP方式部署
该模式下, PON系统参与IGMP协议处理和媒体流转发。组播业务在BRAS/SR、OLT、ONU、机顶盒 (STB) 各节点全程实现。分布式IGMP方式是目前主流的PON网络组播部署方式。分布式IGMP组播业务实现如图1所示。
OLT采用IGMP PROXY, 启用跨VLAN组播:每个用户一个独立的单播VLAN, 所有用户共用一个组播VLAN。点播在单播VLAN中传送, 上行IGMP协议报文在OLT上进行VLAN转换, 并在组播VLAN中传送。组播业务流和下行IGMP协议报文在组播VLAN中传送。ONU为节约资源一般采用IGMP SNOOPING方式, 其内部亦支持跨VLAN组播。下行组播流和IGMP报文采用TAG方式下发, 在家庭网关 (HGU) 上对组播VLAN进行剥离后送到机顶盒。
(3) 部署要点
1) 机顶盒采用IPoE/DHCP方式动态获取接入地址, 地址由上层设备动态分配;
2) IGMP协议通过业务VLAN转发, 与组播MVLAN区分, 建议采用PUPSPV方式划分;
3) SR、OLT、ONU全程配置统一的组播MVLAN。该MVLAN用于组播流分发, 不与其他VLAN冲突, 一般采用单层透传;对FTTB和FTTH, 组播流均分发至ONU;
4) OLT配置IGMP proxy, ONU配置IGMP snooping, 建立和维护组播组和PON口 (用户端口) 的转发关系表。
5 xPON承载IPTV组播的优化策略
上述基本部署策略可以保证组播和其他业务稳定运行。当用户数量和业务需求不断增加的情况下为提升用户体验可从组播配置、QOS以及带宽扩容几方面进行相关优化。
(1) xPON承载组播业务的增强型配置
1) 静态组播和预加入组播
PON系统提供静态组播和预加入组播的增强功能。通过将组播媒体流直接引入到xPON系统内部以减少业务交互时间, 以提高业务体验。
静态组播:OLT设备上配置静态组播组成员, 将组播数据流直接引到ONU的上联口。静态组播对于OLT来说业务是透明的, 通常用于在ONU上作组播控制;
预加入组播:OLT定期向源端口发送IGMP加入报文。预加入组播可以预先将组播流引到OLT设备上联口, 从而减少交互延迟;
2) 端口组播参数配置
组播端口的快速离开和最大组播组限制可在一定场景下控制用户行为并节约带宽。
快速离开:当OLT设备收到IGMP离开报文时, 立即中断组播业务以节约系统带宽。但如端口下接有多个用户, 则不能使用此功能, 否则会导致其它用户观看的相同节目中断;
最大组播组限制:OLT设备配置用户同时能访问的组播节目数, 主要用于控制用户端口的组播带宽, 以及用户家中同时使用的终端数目。
(2) xPON承载组播业务的QoS策略
IPTV业务对丢包敏感, 但对时延要求较低, 因此组播业务在网络中可配置为中等优先级业务。在ONU接入侧, IGMP report报文主要通过802.1P来标记;下行媒体流Qos标记有边缘路由器产生, 经过OLT、ONU进行SP调度。
1) 下行方向:对于OLT上联口, 进来的是带TAG的报文, 本身就带有优先级信息, 该标记由BAS或路由器提供, 对原有优先级通常保持不变, 也可以通过ACL测量进行修改;
2) 上行方向:对于ONU用户口, 如果进入报文带有VLAN标记, 和OLT上联口处理情况相同;若不带VLAN标记报文, 可端口缺省优先级来配置优先级。
(3) xPON承载组播业务带宽扩容策略
采用组播SCB技术可以减少同一组播视频业务对带宽的占用, 但不同的视频业务仍然会占用较大的带宽。因此在组播业务开展到一定规模下, 必须考虑对带宽进行扩容。
1) 多上联口扩展网络侧带宽的策略
在总用户数量/业务一定情况下, 网络侧带宽是xPON设备承载业务扩容的主要瓶颈。通过提升单链路最大带宽或通过链路聚合方式可有效完成网络侧带宽能力的提升。
上联单端口带宽最大可以提升至10G, 目前上联端口普遍为1G带宽。因此通过物理硬件上扩容可以完成对缓解业务带宽瓶颈;
在单上联口带宽有限的情况下, 通过多上联口链路聚合方式提升上联带宽瓶颈。从而实现对上联带宽的简单扩容。
2) PON口带宽扩展对提升用户速率的影响
除上联口外, PON口带宽对下接ONU的组播业务有明显影响, 有效提升PON口最大带宽是组播业务质量提升的有效途径。10 GEPON是目前可行的实现方式。
10G EPON采用IEEE 802.3av标准, 其核心内容包括:扩大802.3ah标准的上下行带宽, 达到10G速率;与1G EPON兼容, 10G EPON的ONU可以与1G EPON的ONU共存在一个ODN下, 从而具备良好的兼容性和灵活的操作性。目前10GEPON在PON网络建设中, 特别是用户业务流量巨大的场景下已经得到了实际应用和检验。
6 结束语
组播用户数量增长以及高质量组播业务需求和设备实际能力之间互相促进发展:在设备容量或总带宽受限的条件下, 通过充分利用xPON内部工作机制, 合理规划组播部署策略达到对有限带宽的充分应用, 确保高优先级业务和重点用户的应用需求和网络安全。同时通过优化策略突破实际带宽的瓶颈, 为组播业务提供更可靠的业务体验以及更广阔的发展空间。
摘要：在PON网络中大规模部署的IPTV组播业务对网络质量稳定和用户感知影响很大。本文试图从网络特点、实现流程、部署策略等角度分析PON网络承载IPTV业务面临的挑战以及可行的解决方案, 并从技术发展角度阐释今后一段时间内IPTV业务发展优化的方向。
关键词：IPTV,IGMP组播,PON承载网,光线路终端,光网络单元,SCB
参考文献
[1]接入网技术要求——EPON系统互通性要求070118.
业务部署 篇9
Envivio与自己的合作伙伴——总部设在维也纳的奥地利本地市场专家TV-Connect Broadcast Systems公司合作, 为奥地利A1 Telekom的部署项目提供了销售和安装支持服务。
A1 TV于2006启动运行, 是奥地利发展最快的电视业务, 现已进入了八成奥地利家庭, 拥有超过20万户用户。该公司基本的服务包包括了150多个电视频道, 外加30个高端电视频道, 集成视频库中保存有2000多部电影和剧集, 还有大量的高清内容可用于提供点播服务。
2010年, 奥地利A1 Telekom第一次投资部署了Envivio 4Caster编码器来提供一项业务, 使用户可以通过IPTV机顶盒和3G移动设备观看直播和点播内容, 包括体育赛事、电影和电视节目。新Envivio编码器可以把视频内容格式化、转码和打包成Apple HTTP Live Streaming (HLS) 和Microsoft HTTP Smooth Streaming (HSS) 格式, 实现多屏观看。
TV Connect公司的CEO Walter Winzel说:“Envivio提供了功能丰富的新一代解决方案, 可以帮助运营商提供高质量的多屏服务。Envivio 4Caster编码器在优化视频质量的同时, 还降低了交付内容的码率, 我们与Envivio在A1 TV IPTV部署项目上的合作大获成功, 为客户带来了更多的业务。”
Envivio总裁兼CEO Julien Signès说:“A1 IPTV业务的服务方式颇具创新性, 他们在多个平台上提供了出色的电视服务。我们对像A1 Telekom Austria这样的老客户倍感珍重, 一直在竭尽全力地为他们提供非凡的解决方案, 以出色的性能和完善的功能帮助他们把电视和多屏视频业务提高到新的高度。”