免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 3158 | 回复: 0
打印 上一主题 下一主题

[容灾] 发一个实时灾备的方案供大家参考! [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2009-11-20 14:36 |只看该作者 |倒序浏览
2.1.2.1:正常复制:
源端        目标端
主交易系统        目标端一:异地灾备系统
        目标端二:本地灾备系统
2.1.2.2:灾难发生复制:
A.主生产库无法工作宕机但本地灾备可以正常使用
此时由灾备系统接管业务,数据复制模式为一对一:
源端        目标端
本地灾备系统        目标端一:异地灾备系统
当主库恢复正常到切换到正常复制模式期间采用如下复制模式:
源端        目标端
本地灾备系统        目标端一:异地灾备系统
        目标端二:本地主生产库
之后恢复正常复制模式。
B.当发生地区性地震致使主生产库和本地灾备系统都不能使用时,此时没有复制功能,应用数据将入库到异地灾备系统,不影响应用的运行,当主交易系统和本地灾备系统恢复后在有异地灾备系统作为源端与修复好的原主交易系统和本地灾备系统实时同步,之后做切换,恢复到正常复制模式。
2.1.2.3:为了实现数据复制,首先需要安装和配置iStream DDS软件
软件安装包括数据源端和复制目标端的软件安装,二者在安装时都不会对系统的运行产生影响,从而无需业务中断。
同时,iStream DDS的参数配置也非常简单,只需要配置所有参加复制的服务器IP地址和port号,以及参加复制的database的参数等。
复制关系的映射有两种方式:1、以表为单位;2、以用户为单位。对于那些数据库中拥有大量数据表(table)的系统,采用iStream DDS 以“USER”为复制单位的配置复制关系比较简单。

2.2.6.        初始化复制环境、进行初始数据同步
复制环境的建立,首先需要将生产系统中的已有数据初始化同步到目标系统上,或称为全同步,同时记录各种系统状态和映射关系等。因此如何快速、有效的进行复制的初始化环境是使用者关注的问题。
在传统办法中,数据初始化同步过程大都采用数据库的EXP导出/IMP导入工具,将源端数据库数据导出来,通过网络传输至目标端数据库进行导入。或者是借助第三方的备份软件工具,将源端的数据进行备份,再通过磁带运输至目的地,将磁带数据恢复到目标数据库,从而达到首次数据同步的目的。
这种方式存在大量的问题:
1、性能低下:通过Export/Import方式,最大的问题在于性能较慢,对于一个几十GB的数据库,进行一次export/import,则大约费时8-10小时以上。
2、        完全需要手工干预:数据的导出(Export),传输和装载(Import)等过程都需要手工干预和执行。
3、        业务必需停止:在执行export/imp过程中,业务一般需要中断,否则会对性能产生很大影响。
4、易出错:尤其在Import过程中,由于表之间的关联性存在,往往出现由于违反参照完整性规则而导致装载中断,非常难于操作。
而 iStream DDS在复制的初始化同步方面有着非常好的解决方案,这是其它方案所不具备的。IStream DDS集成有数据的初始化同步工具,能够自动化的进行数据的首次同步和出现差异情况下进行重新同步的工作,无需人工干预,维护工作量小,且大大提高了工作效率:
1、速度快:对于几十GB的数据量,在系统正常且带宽充足的情况下,只需要1小时左右就能完成初始数据同步。
2、完全自动化:采用iStream DDS只需要1条命令就完成系统的初始化工作,系统自动进行导出、传输和装载任务,完全无需人为干预,减少出错机会。
3、实现了历史数据和新发生的数据库变化信息的无缝结合,而业界同类软件在此方面要么无法实现无缝结合,要么在首次同步时需要停止业务(数据库不处理任何业务,相当于停机)。
2.2.7.        实时复制复用与安全性
当对系统的初始化同步工作结束后,iStream DDS自动进入实时复制状态,无需手工干预。在数据实时复制的过程中,DDS iStream 支持源端和目标端同时为打开状态,支持目标端可以进行其他业务的运行在同一个数据库上,达到了资源、数据的复用,大大节约了成本。
在本地与异地之间的备份数据进行加密处理,采用本软件特有的DTF文件格式进行数据传输,保证了数据传输的安全性。
2.2.8.        灾难恢复方案
在业务数据库系统发生灾难的情况下,此时可使用灾备数据库首先接管业务,然后进行数据的反向恢复。
具体步骤为:
1、数据库发生灾难,业务交易业务停止。
2、修改数据库TNS的指向,将业务指向灾备的数据库,接管业务。
3、应用系统重新连接灾备数据库,完成业务接管。
4、停止iStream DDS复制进程。
5、排除系统故障。
6、恢复原业务系统的Oracle数据库。
7、启动iStream DDS进程。
8、将数据反向批量同步到原系统上,此过程中灾备数据库继续进行业务处理,无需中断。
9、数据重新同步结束后,停止灾备数据库的业务。
10、修改TNS指向,将业务指向原来的(已经恢复的)数据库。
11、应用系统重新连接主交易数据库,完成业务回切。
12、配置iStream DDS进行正向复制。
以上过程是利用灾备中心的系统首先接管业务后,再进行生产中心的修复和数据的反向复制,因此不会造成长时间的业务中断。理论上,数据库的切换只涉及IP地址的切换,没有复杂的数据卷挂载和数据库启动的过程,在业务人员具有熟练技术和完善流程的情况下,数分钟内能够完成数据库的灾备切换。完全满足行业内1小时业务中断的要求。
对于原生产系统的恢复时间,由于可能涉及到硬件的故障问题,很难有明确的界定,但iStream DDS的实时数据保护能够最大程度的避免数据的损失,从而保证了系统恢复的成功率和最短恢复时间。
2.3.        灾备系统的有效性
2.3.1.        数据丢失情况
iStream DDS解决方案在一般性灾难发生时不存在数据丢失。这些一般灾难包括数据库失败、操作系统失败等等。对于一些极端的情况下,掉电、站点失败时,iStream DDS也做过大量测试,不会出现数据丢失(但从理论上讲这些极端情况无法100%避免数据丢失,因为这种情况可能造成了系统的严重破坏)。
        网络失败:网络恢复时继续复制,没有数据损失。
        数据库关闭:数据库恢复时从断点继续复制,没有数据损失。
        操作系统重起:重新启动复制软件,从断点处继续复制,没有数据损失。
        掉电:iStream Replication也做了大量测试不会出现数据丢失(但从理论上讲这些极端情况无法100%避免数据丢失,因为这种情况可能造成了系统的严重破坏)。不过对于重要的生产系统一般通过UPS预防断电情况,发生概率非常小。
        源端灾难:由于目标系统在线可用,不存在任何数据风险。但对于还没来得及传输到目标系统的数据可能出现丢失。
2.3.2.        数据延迟
iStream DDS是一种异步准实时的复制技术,其数据延迟非常小。数据延迟的周期可以设置,在生产系统中,数据延迟和源系统复制事务的多少,事务的处理方式有关,以及跟设置的log数据轮询周期有关。在复制数据量正常的OLTP系统中,数据延迟一般在秒级(2~7秒)。
2.3.4.        事物的完整性和可用性
iStream DDS是一个数据库级的软件解决方案,其复制的基本单位就是一个事务(Transaction),iStream DDS在从Oracle log中读取到交易数据后,根据交易的关系,将属于一个事务的所有操作组合在一起,以一个基本单位发送给目标端,目标端在执行时也严格按照交易进行,因此严格保证了交易的完整性。
对于事务与事务之间的顺序,iStream DDS严格按照Oracle 的SCN标记进行排序。确保事务之间的先后秩序。
2.3.5.1.        对源系统性能的影响
与其它类型的复制产品比较,iStream DDS要求的整体系统资源很少,网路带宽占用低等特点。无须采购指定型号的硬件,如磁盘阵列;不需要特殊基础软件配合,如专用文件系统;也不需要应用软件支持,完全无关。
对于整个复制系统的资源使用,单点系统平均的CPU利用率为5%以下,内存使用小于100MB,在没有交易处理工作的时候,不占用系统资源。这样的资源使用基本不会对数据库的运行产生任何影响。
同时,iStream DDS在安装调试过程不会改动数据库的主要配置,也不涉及文件系统、操作系统和数据卷。完全能够在业务系统不停机甚至工作状态下实施安装、调试。而其他的解决方案可能需要停机,甚至改动软硬件的配置。对生产系统将会产生较大的影响。
2.3.5.2.        对网络资源的使用
iStream DDS方案所需网络带宽很少,远程支持2M带宽的实施复制,数据延迟为10秒以下,本地延迟可控制在3到5秒以内,能够在有限传输带宽上保证复制工作不延迟。
因为iStream DDS复制操作只是读取操作系统的日志文件,同时通过TCP/IP方式而不是采用中间键方式传输只发生改变的数据也使网络负载降至最低。通常情况下iStream DDS传输的数据量只相当于日志的三分之一,而且传输过程中还有压缩机制,最终要传输的实际数据量约为总数据量的九分之一。
2.3.5.3.        对系统扩容的影响
iStream DDS解决方案对今后的扩容没有任何影响。使用iStream DDS,源数据库和目标数据库可以运行在不同类型的操作系统和同一Oracle数据库的不同版本上。同时,也能够支持不同类型的磁盘阵列。这不仅能够满足目前异构环境,还能适应未来的扩展需求。随着业务量规模的不断扩大,在硬件升级时,新旧硬件产品可以随意调换,不受限制。
3.        附录(一):iStream DDS产品介绍
3.1.        概述
iStream DDS是基于分析Oracle redo log技术的Oracle实时复制工具,具有简单灵活、高性能低成本的特点,部署和使用非常容易,对系统资源和运行环境的要求也非常低。iStream DDS能够帮助用户在复杂的应用环境下完成容灾备份、异构迁移、业务数据分发、基础数据整合集中等工作。
        iStream DDS能做什么?
IStream DDS能够满足用户多种业务需求,主要有:
1、提高系统整体可用性
iStream DDS能够帮助用户提高Oracle数据库的可用性,无论是执行计划内停机(如系统升级、备份)还是遇到故障引起的非计划宕机(例如硬件故障、灾难、人为错误等),iStream DDS都能尽量减少宕机时间。提高可用性能够最大限度地减少数据丢失、经济损失和生产力的降低。
2、逻辑灾备和灾难恢复
对于大部分公司而言,灾备是一项巨大的工程,意味着高额的资金投入和人力成本。受到传统复制技术的限制,灾备必须拥有专用的硬件支持和专用的光纤传输链路,灾备距离和系统平台还有诸多的限制。此外,由于传统灾备系统的数据库不能随时打开使用,不但风险不能评估,而且巨大的投入也得不到回报。
iStream DDS使用逻辑数据复制技术,传递的是交易信息,因此传输数据量很小,保证了在低带宽环境下实现低延迟的Oracle数据异步复制,软件同时支持实时复制容灾和定时复制备份功能,是一种高效且低成本的数据库灾备方式。
iStream DDS没有距离限制,此外,容灾端数据库始终处于打开状态,因此,当生产数据库遇到计划内或非计划停机时, iStream DDS能够支持前端应用程序快速、无缝的切换到灾备数据库。与其它基于磁盘或文件系统的物理复制技术相比,不但省略了漫长的数据库recovery和启动时间,而且能够保证100%的切换成功率。
3、分担数据库负载
iStream DDS逻辑交易复制技术保证了目的端数据库始终处于可用状态,因此对于实时交易处理之外的只读应用,例如批量查询、报表处理、数据备份、统计分析等都可以交给复制的数据库处理。多种应用也不必在同一个交易数据库上争夺资源和时间窗口。生产系统运行和维护的压力得以释放,提高了稳定性,而不同的应用在各自的数据库上也可以得到分别的优化。
4、业务数据分发
iStream DDS能够完成企业范围内数据分发,从生产数据库实时复制到一个或多个本地或异地的数据库。iStream DDS支持多种数据分发拓扑结构,一对多,多对一,级联复制等。数据分发是一种典型的通过部署多服务器、多数据库来分担负载,提高响应速度的企业应用模式。
5、跨平台数据迁移
iStream DDS支持跨平台的数据传输,复制的源和目的系统可以在AIX、HP-UX、Solaris、Linux之间任意选择。iStream DDS同时支持Oracle 9i和Oracle 10g。对于用户来说,不但硬件平台的选择有很大的灵活性,也可以用iStream DDS来完成异构平台的数据库同步和迁移工作。
6、实时复制和批量复制
应用的需求影响着用户使用复制工具的模式,对于容灾和查询应用,连续的实时复制保证目的端数据库拥有和生产系统完全一样的数据状态,而对于定时备份、系统升级和定时分析等应用,用户则希望复制软件做到定时或周期性的批量数据迁移。在iStream DDS中批量复制和实时复制是相互独立又紧密结合的两个部分,通过管理员的操作控制,iStream DDS完全满足用户在多种应用条件下的需求。
8、增强分析工具
iStream DDS提供了简单实用的数据库工具包,包括日志分析工具、文件分析工具、导入导出工具等,工具包能帮助有经验的DBA更深入的分析处理数据库的问题。
3.2.        iStream DDS技术原理
3.2.1.        iStream DDS和Oracle Redo Logs
        基于日志分析的实时复制技术:
iStream DDS通过分析Oracle redo log获得实时交易信息,完成schema或table级别的数据复制。区别于早期的日志分析技术,iStream DDS对日志的整合和传输以交易为单位,使用该技术,在拥有高性能的同时还能更好的保证数据传输的一致性和完整性。对生产数据库也不会增加负载。
iStream DDS从Oracle redo logs里面获取所有的数据库改变信息。通过对信息的分析整合,iStream DDS将完整的交易信息复制到目的端。
iStream DDS不是等待Oracle redo log文件写满之后再处理,而是随时读取其数据块内容,间隔时间可以用参数指定,一般是秒级。iStream DDS也不会复制Oracle redo log的全部内容到目的端数据库,除指定复制对象(数据表)相关的DML/DDL操作之外,其他的信息将丢弃处理。
为了避免可能出现的复制错误,用户需要打开数据库的supplemental logging 和force logging参数以便iStream DDS能获取完整的数据信息。
置于裸设备或文件系统(包括ocfs)中的Oracle redo log可以被iStream DDS正常读取。如果用户使用的是Oracle 10g,并且将redo log保存在ASM(一种新的Oracle存储格式)中,则需要在裸设备或文件系统上手动创建一组与原有日志同步的redo log member,供iStream DDS复制使用。
        3.2.2.        复制对象和数据定位
        复制对象的指定:
iStream DDS支持两种级别的复制:1.用户(schema)级复制;2.表级复制。
用户级复制表示源端数据库指定用户(schema)下的所有表、视图、索引、过程、函数、包、序列等数据对象全部复制到目标端数据库指定的用户下。
表级复制表示源端数据库指定用户(schema)下的单个表复制到目标端数据库指定用户下的单个表。
在使用iStream DDS时,用户通过编辑配置文件指定源端和目的端复制对象的映射关系,包括源端对象名,目的端对象名,目的端主机编号等。源端和目的端对象名称可以不同,但结构必须一致。软件运行过程中,复制对象的映射参数会驻留内存,iStream DDS通过日志分析过滤,只处理指定复制对象有关的交易,其它用户或表的操作信息则被丢弃。
为了满足海量数据系统的应用要求,iStream DDS以Oracle内部rowid为参照进行复制数据定位。系统在初始化过程中会自动创建源端数据行和目的端数据行的rowid mapping映射表,为二进制格式,系统根据该映射关系找到DML操作的目标行。Rowid定位技术在海量数据环境下处理Update和Delete操作具有较大的性能优势。
3.2.3.        分级存储和交易队列
iStream DDS在数据传输部分使用了分级存储机制,在遇到系统错误引起的复制中断时,例如硬件故障、数据库故障、网络中断或延迟,分级存储机制能完好的保存已经合成的交易信息,避免数据丢失。这些数据以二进制文件格式存储在文件系统的缓存目录下,直到系统故障解决。恢复从缓存文件传输的中断点开始。
        源端和目的端分级存储:
iStream DDS的分级存储分为两级:第一级在复制源端,第二级在复制的目的端。Redo log里边的交易的信息被整合成缓存文件后,首先存放到源端的一级缓存目录;然后经过网络通讯进程处理被发送到目的端系统下的二级缓存目录保存;最后由装载进程负责装载到目的端数据库中。


在网络传输出现中断或大量延迟的情况下,iStream DDS在源端仍然继续读取并分析数据库日志产生的交易信息,这些信息暂时不能发送到目标端系统,不断地积累在源端的缓存目录下,直到通讯恢复。源端缓存保证了故障情况下复制数据的完整性。
目的端的缓存目录将保存交易信息文件直到它们正确的装载到目的端的数据库内,如果因为目的数据库的故障或关闭,装载不能进行,从源端传送过来的数据文件将在目的端缓存目录下保存。数据库恢复后,缓存文件会严格按照交易时间顺序进行装载。
        文件的格式和大小:
交易信息以文件为单位进行传输、缓存和装载,该文件为iStream独有的二进制格式,其内部的表达方式与Oracle内部处理方式相类似,避免了很多复杂的信息转换,因此具有很高的效率。
缓存文件的总量为源端实际产生redo log日志量的1/3~1/4左右。iStream DDS不设置缓存空间控制机制,用户可以根据每天交易产生的Oracle redo log日志量和以上比例计算需要预留的缓存空间。
        内存管理和大交易处理:
iStream DDS启动后,将在源端和目的端系统上开辟多个内存区供各进程使用,用来驻留参数、传递消息信号、缓存分析交易的中间信息等。内存区的大小由系统参数指定,目的是防止无限制的使用内存引起系统资源紧张或系统崩溃。
在复制源端,如果遇到数据库产生非常大的交易,iStream DDS会连续分析直到整个交易提交,其间产生的中间信息可能达到GB级。在这种情况下,iStream DDS会自动将这些信息缓存在磁盘上等待处理,磁盘缓存由后台进程自动处理,容量没有限制。
        交易队列:
iStream DDS严格按照Oracle数据库内部SCN顺序执行交易的复制和装载,保证复制数据的绝对一致性。
iStream DDS在跟踪redo log过程中,每隔一个固定的时间(通常是秒级)读取一次日志文件,分析出本次读出数据的内容,同时记录下该段数据的起始和终止SCN号。下一次读取redo log时,从上一次获取的终止SCN位置开始。多个实例的RAC模式下,则以SCN为参考给每个实例执行的交易进行排队,然后按照排队顺序形成缓存文件。缓存文件也严格按照交易的顺序进行编号、传递。所有的交易在目的端装载的顺序与它们在源端产生的顺序完全相同,这是保证数据完整性和一致性的关键。
3.2.4.        使用和部署iStream DDS
        在线部署:
iStream DDS的安装非常简单,不需要特殊的软硬件支持,软件本身完全在Oracle数据库的外部,不需要在Oracle中增加表空间,不需要在复制的表上添加索引和主键,也不需要停机做基础数据同步工作。
整个安装过程可以在线进行,甚至可以在数据库正常执行交易的过程中执行,因为iStream DDS不用借助任何第三方工具就可以进行在线的批量数据初始化工作,初始化结束后,无缝切换到增量数据复制过程。这样的功能对于一些需要7*24连续运行的系统来说非常重要,因为在安装维护过程中,频繁的停机会给生产系统带来很大的安全隐患和工作难度。
        跨平台支持和兼容性:
使用逻辑复制技术的iStream DDS,其跨平台能力是用户非常欢迎的。iStream DDS能够支持不同版本Unix/Linux系统下的混合复制,对于具有复杂硬件环境的企业系统来说,异构能力可以节省大量的资源和成本,旧设备得到充分的利用。
不同Oracle版本的支持能力也非常有价值,对于一些7*24运行的Oracle9i数据库来说,iStream DDS可以帮助它们在线的升级到Oracle 10g。
操作系统        数据库版本        数据类型        数据对象
AIX        Oracle9i        NUMBER         Table
HPUX        Oracle9i RAC        CHAR        View
HPUX(IA64)        Oracle10g        VARCHAR/VARCHAR2        Package
Solaris        Oracle10g RAC        DATE        Package body
Linux                TIMESTAMP        Index
                BLOB/CLOB        Sequence
                RAW/LONG RAW        Procedure
                ROWID        Function
                UDT        Trigger
                        Synonym
                        Privilege
表1:iStream DDS支持的系统及对象
        多种复制模式:
iStream DDS支持一对一,一对多,多对一,以及级联复制等多种复制模式。无论在哪种模式下,复制的源和目的系统都是独立的部分,可以单独的使用、维护和优化,这也是逻辑复制技术受到用户青睐的重要原因之一。
一对一的复制常见于灾备应用:





多对一的复制常见于数据集成应用和集中灾备:







一对多的复制能够同时将数据备份到多个地点,也是企业数据分发,数据库负载均衡的手段:





        
级联复制也是灾备的重要形式:






3.2.5.        iStream DDS交易回退模块
1、软件说明:
iStream DRS是数据恢复模块,Data Rollback Software的简称。利用DDS产生的交易合成文件,在容灾端将源端操作的事务以交易为单位进行恢复操作。iStream DRS 不依赖数据库本身的恢复工具,具有速度快、操作简单、灵活的特点。对源端数据库没有任何影响。iStream DRS 主要适用于数据库逻辑操作(包含人工误操作)的数据恢复领域。
2、需求背景:
通常来说,一个核心交易系统通常由多种业务组成,每种业务的数据存放在不同的表中,管理员在操作这些表时,可能会因为某种原因将某些业务的关键数据表误删除或修改了,通常恢复关键业务表数据的做法有以下几种方式:
        采用Oracle的flashback(10G中经常会使用)
        另外一种办法是采用物理回复
        采用业务系统讲相关业务重现做一次
这几种方式中:
采用第一种flash恢复时,由于空间、时间等的限制,导致数据彻底丢失的可能性大大存在,另外使用flashback恢复时,由于无法确切的知道恢复的时间点而导致操作过程比较长从而影响到业务的正常进行。
采用第二种物理恢复方式,由于操作复杂,时间漫长,并且恢复时间点难以确定,也会影响到业务的正常进行。
采用第三种方式恢复时,由于部分业务之间的数据可能存在关联关系,因此也会对另外的业务产生一定的影响。
因此如何快速的恢复关键业务表的数据,同时尽量减少当前系统的业务是管理员面临的一个难题。
3、iStream DRS实现机制:
        
DRS实现机制请见下图所示:
         

iStream DRS是在DDS运行基础上进行恢复的,是在容灾端实现的,对核心交易系统不会产生任何影响。实现快速恢复的机制如下:
        通过DDS软件在目的端进行同步后,DRS会形成交易合成文件dtf列表。
由于DDS纪录了每一笔交易的业务,通过DDS运行的日志DRS提供的工具可以查看每一笔业务的交易情况,从而可以清晰的知道恢复的交易时间点以及恢复所需要使用的交易合成文件号。
通过DRS软件,手工将所需要恢复的合成交易文件反向提交到数据库中,一直到指定的合成交易文件为止。
容灾端所需要恢复的交易在恢复完成后,由于容灾端数据库一直处于open状态,可以通过exp或其他方式取得数据。通过imp或其它方式导入到交易系统数据库中,从而能够快速的恢复关键业务表的数据,在很短时间内能够恢复数据,减少业务停止时间。
在容灾端通过exp方式取得数据后,将已经反向恢复的交易合成文件重新正向提交到容灾端数据库中,从而保证了iStream  DDS数据同步的一致性和连续性。
使用DRS恢复数据的方式,对于当前交易系统没有任何影响,而且可以快速的恢复核心交易系统的数据,使其它业务交易正常进行。
4、iStream DRS支持的操作:
DRS目前支持的范围有insert、update、delete三种dml操作,以及create table,drop table,truncate table三种ddl操作。
DRS不仅支持整个数据库交易的恢复,也单独支持指定表数据的恢复,从而满足了不同的恢复需求。
3.2.6.        iStream DDS监控管理软件
iStream DDS监控管理模块,通过web页面对源端、目标端DDS运行过程进行监控管理的模块。
DDS监控管理模块是通过独立的后台进程对DDS进行管理监控的模块,无须第三方web服务软件协助。
ISTREAM DDS Web监控的应用
WEB监控说明
ISREAM DDS web监控是新一代数据复制应用管理解决方案,它可以帮助用户监控和管理异构复制环境中的关键服务与资源。这一安装、使用都十分简便的解决方案具有强大的监控能力,只需用一条命令就能投入使用。ISTREAM DDS Web 用系统资源少、具有高度可扩展性,并支持全系列IStream数据管理软件的配置和监控。它通过新的单一门户界面— IStream统一管理门户— 将多种软件的管理整合在了一起。它是一款真正端到端的管理解决方案,能够跨Microsoft、Linux以及Unix等操作系统来有效地管理性能和可用性。

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP