首页 IDC机房的维护与运行

IDC机房的维护与运行

举报
开通vip

IDC机房的维护与运行IDC机房的维护与运行 IDC机房的温度、湿度、电压要求 2011-06-19 16:38:16 标签:IDC机房 温度 电压要求 湿度 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。 机房温度:20-25 摄氏度之间 机房湿度:相对湿度40-70%之间 机房电压:220伏 ps,最好能有柴油发电机,并能保证和 另外,机房应该至少有2路以上的供电,至少有u 供油站有协议。 如何才能管理好IDC机房, 我入行11年了,做机房管理工作将近6年,...

IDC机房的维护与运行
IDC机房的维护与运行 IDC机房的温度、湿度、电压要求 2011-06-19 16:38:16 标签:IDC机房 温度 电压要求 湿度 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。 机房温度:20-25 摄氏度之间 机房湿度:相对湿度40-70%之间 机房电压:220伏 ps,最好能有柴油发电机,并能保证和 另外,机房应该至少有2路以上的供电,至少有u 供油站有协议。 如何才能管理好IDC机房, 我入行11年了,做机房管理工作将近6年,就如何管理好IDC机房谈谈自己的体会,希望能够起到抛砖引玉的效果,对从事机房工作的同行有所借鉴,也请同行多指点。 机房管理的目的是什么,机房的管理有三个方面 1 保证业务正常上线 2 维护机房稳定,保证业务正常运转 3 根据业务需求,做出实时调整。 要做好机房管理,应做好以下几个方面。 1 了解机房环境和资源 这个是最基本的,所谓知己知彼百战不殆,熟悉机房环境,就是要做到知己。对机房的有关信息要做到了然于胸,如数家珍。比如机房总共有多少个机柜,使用了多少个,还剩多少;机房的电力情况怎么样;机房的空调情况怎么样;机房的网络资源如何,带宽和ip等。 2 一定要做好备份 做好备份是使自己立于不败之地的最好的途径,是机房管理的一大法宝。比如,核心交换机突然坏了,如果你有配置的备份,换了新的交换机上去,就能很快回复。核心业务的数据库服务器彻底坏了,如果有备份,就不会损失严重,如果有条将,不仅要热备,主要核心数据建议要采取冷被的方式,刻录光盘,磁带库等。如果能做异地备份,那么就是碰到地震等比较大的灾害也能很快的恢复业务。 3 要有一定数量的备用设备 机房最重要的一个特点就是要维持稳定,如果有设备故障,有备用的设备顶上去,是最快的恢复故障的方式。当然这个还要算经济成本,要取得一个平衡,最起码做到核心设备有备份。或者备份的机制,比如ha的方式。 如何管理好IDC机房,(二) ----依靠技术还是管理 在机房管理中有两个派别,管理派认为要依靠严格的管理,明确和细致的制度,来达到目的;而技术派则认为应通过不断的技术进步来推动管理,提高效率。 一般持有倾向管理观点的人,大多不是很懂技术,为管理人员出身。而技术派一般是有良好的技术基础,很多人就是机房出身。 在实际工作中,两种类型的 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 我都接触过,而且两种方法在现实中我都看到过实例,都将机房管理的都很好。 倾向管理的人,可以将制度做的很细致很明确,比如规定电源线捆扎到左边,网线捆扎到 右边;每个机柜如何放置机器,1U的机器怎么放置,2U的机器怎么放置;规定ip标签具体粘帖到机器的什么位置等等。这样的好处是在最大程度上维持了机房的稳定运转。 倾向技术的人,喜欢尝试新的技术,比如引进kvm over ip,使用ilo imm 远程管理,采用网络技术完成操作系统的安装等。这种方法最大的好处是提高了效率。 当然,最好的管理方法是二者的结合,管理出身的人要学习技术,技术出身的需要学习管理。应用新的技术的同时,要制定明确细致的 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 和制度。 ----机房管理中的文档及文档管理 为什么需要文档, 这个不难理解,文档是管理好机房比不可少的,良好的文档就是机房良好运行的体现。个人认为,判断机房文档管理好坏的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 就是,如果机房的所有管理人员全部离开,来了一批新人,很快就能上手,这就是成功的机房文档管理~ 机房文档应该包含以下内容 1 网络方面 a 网络拓扑图 b 网络设备配置文档,网络设备配置文档应该包含常用接入层交换机的配置模版及所有重要网络设备配置的备份。 2 设备信息 a 服务器、交换机、防火墙等硬件及配置信息,比如服务器信息应包含,品牌 型号 cpu 内存 硬盘 等详细信息。 b 机柜 空调 电力等设备信息 3 网络资源信息 a ip 信息,包括网络划分,ip 使用和备用情况等 b 带宽信息 4 相关联系人信息 a 内部联系人信息 b 外部联系人信息 5 日常工作流程及规范 a 设备使用规范 b ip 使用规范 c 带宽使用规范 d 机柜使用规范 e 设备上架操作规范 f 设备下架操作规范 g 机房常见问题维护手册 文档如何管理 1 认真执行,并且有奖励和惩罚措施,要不就是空谈。 2 文档应根据实际变更及时更新和维护。 对于上了一定规模的机房,应建立一个b/s的系统,维护机房的设备信息和文档更新。 ----机房安全管理 机房大部分设备都在公网上,安全工作搞不好,轻则影响业务运行,重则可能会丢失数据,造成不可弥补的损失。 安全管理的两个方面 1 每个人都要树立安全思维,只有在思想上引起重视,安全措施才会落实,要不就是采取一百层的安全措施,一切也是空谈。 2 技术方面 根据我的经验,采取一下技术措施,可以有效实现机房安全管理。 1) 复杂口令,定期更换。如有条件建议采取令牌认证等认证手段。 2)根据业务需求,win服务器采用ipsec lin服务器iptables 网络设备编写acl,关闭一切不需要的端口,最好能搞一个基础模版,然后根据不同的业务修改。 3)远程控制服务尽量采取不常用的端口,比如修改远程桌面,vnc ssh 等端口为高端口,同时要限制登录ip。 4) 重要数据走内网,应用服务器和数据库服务器之间通讯依靠内网,尽量不要走公网,一方面减小公网压力,节约带宽,一方面更安全。 5)定期扫描和杀毒,尽量在凌晨或者非业务运行时间查毒,建议采取只查不杀的策略,如果检查去病毒或者木马,手工处理,因为服务器上一般都是重要应用,防止误杀造成损失。每个杀毒厂家都有免费查毒的服务,刚好可以利用,可以做简单的开发,能达到自动执行的目的更好。 如何管理好IDC机房(五)----云计算和虚拟化在机房管理中的应用 2011-06-29 06:47:28 标签:IDC机房 云计算 虚拟化 机房管理 idc 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。 相信为什么要在IDC机房中使用虚拟化,这个应该都没有疑问了吧,使用虚拟化技术,可以充分挖掘多核服务器性能,在按照机柜空间来收费的IDC,等于一台机器顶好几台使用,节约了空间,节约了设备,节约了费用。 关于使用那种虚拟化产品,当然目前还是首推vmware了,从市场份额来看,目前市场份额还在70%以上。如果不想花钱,开源的kvm也是一个选项,kvm和vmwware的性能不相上下,但是管理便利性还有待逐步提高。 理想的机房虚拟化架构应该是什么样的,应该使用云技术~不管是自建的IDC,还是出租给客户的IDC,如果能像使用水电一样的使用服务器,那对机房的管理就是一个巨大的提升。基础架构应该是按照一个或者多个机柜为一个虚拟化单元,每个单元包括多台的虚拟化物理机和两台或者多台存储,物理机用来做虚拟化,所有的虚拟化镜像和数据都存储到存储上。 利用虚拟化的迁移技术来实现云计算,根据需要,虚拟机可以在物理机之间迁移。或者动态的增加虚拟机,增加虚拟机只需要编写简单的脚本,如果有实力,应开发一套管理系统,以方便的实现虚拟机的扩展和迁移。 对服务器使用者来说,这都是透明的,他们只是需要想以前一样的来使用服务器就行,但是对IDC管理者来说,虚拟化和云计算将大大减轻机房工作,更好的提高机房效率。 如何管理好IDC机房(六)----机房网络架构 理想的IDC机房网络架构应该满足以下要求: 1 稳定 保持业务稳定是最基本的要求。 2 有良好的可扩展性 良好的网络设计能应该能满足业务的需求,随时平稳扩展 3 能够充分利用带宽和ip等资源 在IDC里面,带宽和ip都是金钱,良好的网络设计应充分考虑这个因素。 就个人经验,我建议机房采用二层的网络架构。建议需要不需要,全部架设、作者信息和本声明。否则将追究法律责任。 上个月跟某个朋友谈及多IDC数据同时读写访问的问题(tweet),当时觉得有不少解决方案,但觉得思路还不够清晰。最近看了Google App Engine工程师Ryan Barrett介绍GAE后 端数据服务的演讲稿Transactions Across Datacenters(视频),用Ryan的方法来分析这个问题后就豁然开朗。 按Ryan的方法,多IDC实现有以下几种思路。 一、Master/slave 这个是多机房数据访问最常用的方案,一般的需求用此方案即可。因此大家也经常提到“premature optimization is the root of all evil”。 优点:利用mysql replication即可实现,成熟稳定。 缺点:写操作存在单点故障,master坏掉之后slave不能写。另外slave的延迟也是个困扰人的小问题。 二、Multi-master Multi-master指一个系统存在多个master, 每个master都具有read-write能力,需根据时间戳或业务逻辑合并版本。比如分布式版本管理系统git可以理解成multi-master模式。具备最终一致性。多版本数据修改可以借鉴Dynamo的vector clock等方法。 优点:解决了单点故障。 缺点:不易实现一致性,合并版本的逻辑复杂。 三、Two-phase commit(2PC) Two-phase commit是一个比较简单的一致性算法。由于一致性算法通常用神话(如Paxos的The Part-Time Parliament 论文 政研论文下载论文大学下载论文大学下载关于长拳的论文浙大论文封面下载 )来比喻容易理解,下面也举个类似神话的例子。 某班要组织一个同学聚会,前提条件是所有参与者同意则活动举行,任意一人拒绝则活动取消。用2PC算法来执行过程如下 Phase 1 Prepare: 组织者(coordinator)打电话给所有参与者(participant) ,同时告知参与者列表。 Proposal: 提出周六2pm-5pm举办活动。 Vote: participant需vote结果给coordinator:accept or reject。 Block: 如果accept, participant锁住周六2pm-5pm的时间,不再接受其他请求。 Phase 2 Commit: 如果所有参与者都同意,组织者coodinator通知所有参与者commit, 否则通知abort,participant解除锁定。 Failure 典型失败情况分析 Participant failure: 任一参与者无响应,coordinator直接执行abort Coordinator failure: Takeover: 如果participant一段时间没收到cooridnator确认(commit/abort),则认为coordinator不在了。这时候可自动成为Coordinator备份(watchdog) Query: watchdog根据phase 1接收的participant列表发起query Vote: 所有participant回复vote结果给watchdog, accept or reject Commit: 如果所有都同意,则commit, 否则abort。 优点:实现简单。 缺点:所有参与者需要阻塞(block),throughput低;无容错机制,一节点失败则整个事务失败。 四、Three-phase commit (3PC) Three-phase commit是一个2PC的改进版。2PC有一些很明显的缺点,比如在coordinator 做出commit决策并开始发送commit之后,某个participant突然crash,这时候没法abort transaction, 这时候集群内实际上就存在不一致的情况,crash恢复后的节点跟其他节点数据是不同的。因此3PC将2PC的commit的过程1分为2,分成preCommit及commit, 如图。 (图片来源::Three-phase_commit_diagram.png) 从图来看,cohorts(participant)收到preCommit之后,如果没收到commit, 默认也执行commit, 即图上的timeout cause commit。 如果coodinator发送了一半preCommit crash, watchdog接管之后通过query, 如果有任一节点收到commit, 或者全部节点收到preCommit, 则可继续commit, 否则abort。 优点:允许发生单点故障后继续达成一致。 缺点:网络分离问题,比如preCommit消息发送后突然两个机房断开,这时候coodinator所在机房会abort, 另外剩余replicas机房会commit。 五、Paxos Google Chubby的作者Mike Burrows说过, “there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos. 意即“世上只有一种一致性算法,那就是Paxos”,所有其他一致性算法都是Paxos算法的不完整版。相比2PC/3PC, Paxos算法的改进 P1a. 每次Paxos实例执行都分配一个编号,编号需要递增,每个replica不接受比当前最大编号小的提案 P2. 一旦一个 value v 被replica通过,那么之后任何再批准的 value 必须是 v,即没有拜占庭将军(Byzantine)问题。拿上面请客的比喻来说,就是一个参与者一旦accept 周六2pm-5pm的proposal, 就不能改变主意。以后不管谁来问都是accept这个value。 一个proposal只需要多数派同意即可通过。因此比2PC/3PC更灵活,在一个2f+1个节点的集群中,允许有f个节点不可用。 另外Paxos还有很多约束的细节,特别是Google的chubby从工程实现的角度将Paxos的细节补充得非常完整。比如如何避免Byzantine问题,由于节点的持久存储可能会发生故障,Byzantine问题会导致Paxos算法P2约束失效。 以上几种方式原理比较如下 (图片来源:) 后文会继续比较实践环境选取何种策略合适。 (PS: 写完后在Google Reader上发现 背景资料 Latency差异 Jeff Dean提到不同数据访问方式latency差异 Numbers Everyone Should Know L1 cache reference 0.5 ns Branch mispredict 5 ns L2 cache reference 7 ns Mutex lock/unlock 25 ns Main memory reference 100 ns Compress 1K bytes with Zippy 3,000 ns Send 2K bytes over 1 Gbps network 20,000 ns Read 1 MB sequentially from memory 250,000 ns Round trip within same datacenter 500,000 ns Disk seek 10,000,000 ns Read 1 MB sequentially from disk 20,000,000 ns Send packet CA->Netherlands->CA 150,000,000 ns 这个数据对于我们设计多IDC数据访问策略具有关键的指导作用,我们可以用这个数据来 衡量数据架构来如何设计才能满足高并发低延迟的目标。 这份数据实际上对所有网络应用及分布式应用开发者都具有很大借鉴作用,数据需要根据 访问频率尽量放在latency小的地方。 1. 2PC/3PC/Paxos模式 在上文中提到,2PC/3PC相比Paxos有明显的缺点,因此最好不用于生产环境,这里就不 再详述。 Paxos选择了CAP理论中的”Consistency, Partition”, 需要牺牲availability。它可以在多个 IDC之间实现强一致性复制。 Paxos缺点 IDC之间需要高速稳定网络 一个2f+1个节点的网络中,需要f+1个节点完成事务才能成功。 Throughput低,不适合高请求量的场合。所以大部分分布式存储产品并不直接使用Paxos算法来同步数据。 2. Dynamo模式 Dynamo论文中并未专门描述Dynamo算法是否适合多IDC场景,只有少量文字提到 In essence, the preference list of a key is constructed such that the storage nodes are spread across multiple data centers. These datacenters are connected through high speed network links. This scheme of replicating across multiple datacenters allows us to handle entire data center failures without a data outage. 从上文看到,前提条件是“high speed network links” 可能对国内的情况不太适用。假如IDC 之间网络不稳定,那会发生哪些情况呢, Quorum 算法中,如果要考虑高可用性,则数据需要分布在多个机房。双机房如NRW=322由于单机房故障后可能会发生3个点中2个点都在故障机房,导致出现数据不 可用的情况, 所以合适的部署是NRW=533,需要3个机房。大部分请求需要2个机房节点返回才能成功, 考虑到多IDC的带宽及latency,性能自然会很差。 Quorum算法在读写的时候都要从quorum中选取一个coordinator,算法如下 A node handling a read or write operation is known as the coordinator. Typically, this is the first among the top N nodes in the preference list. If the requests are received through a load balancer, requests to access a key may be routed to any random node in the ring. In this scenario, the node that receives the request will not coordinate it if the node is not in the top N of the requested key’s preference list. Instead, that node will forward the request to the first among the top N nodes in the preference list. 如果严格按照Dynamo协议,coodinator一定要在N中第一个节点,那在3个机房中将有 2/3的请求需要forward到异地机房的 coordinator执行,导致latency增大。如果对coodinator 选择做优化,让client选取preference list中前N个节点中在本地机房的一个节点作为 coordinator,这样会一定程度降低latency,但是会存在相同的key选择不同节点作为 coordinator的概率增大,导致数据conflict的概率增大。 同时在多机房模式下,Failure detection容易产生混乱。Dynamo并没有使用一致性的failure view来判断节点失效。而是由每个节点独自判断。 Failure detection in Dynamo is used to avoid attempts to communicate with unreachable peers during get() and put() operations and when transferring partitions and hinted replicas. For the purpose of avoiding failed attempts at communication, a purely local notion of failure detection is entirely sufficient: node A may consider node B failed if node B does not respond to node A’s messages (even if B is responsive to node C’s messages). 而最近非常流行的Cassandra基本上可以看作是开源的Dynamo clone, 它在Facebook Inbox Search项目中部署在150台节点上,并且分布在美国东西海岸的数据中心。 The system(Facebook Inbox Search) currently stores about 50+TB of data on a 150 node cluster, which is spread out between east and west coast data centers. 虽然在它的JIRA中有一个提案 CASSANDRA-492 是讲”Data Center Quorum”,但是整体看来Cassandra并没有特别的针对 对IDC的优化,它的paper[5]中提到 Data center failures happen due to power outages, cooling failures, network failures, and natural disasters. Cassandra is configured such that each row is replicated across multiple data centers. In essence, the preference list of a key is con- structed such that the storage nodes are spread across mul- tiple datacenters. These datacenters are connected through high speed network links. This scheme of replicating across multiple datacenters allows us to handle entire data center failures without any outage. 跟Dynamo中的描述几乎是相同的。 3. PNUTS模式 PNUTS模式是目前最看好的多IDC数据同步方式。它的算法大部分是为多IDC设计。 PNUTS主要为Web应用设计,而不是离线数据分析(相比于Hadoop/HBase)。 Yahoo!的数据基本都是用户相关数据,典型的以用户的username为key的key value数 据。 统计数据访问的特征发现85%的用户修改数据经常来源自相同的IDC。 根据以上的数据特征,Yahoo!的PNUTS实现算法是 记录级别的master, 每一条记录选择一个IDC作为master,所有修改都需要通过master 进行。即使同一个表(tablet)中不同的记录master不同。 master上的数据通过Yahoo! Message Broker(YMB)异步消息将数据复制到其他IDC。 master选择具有灵活的策略,可以根据最新修改的来源动态变更master IDC, 比如一 个IDC收到用户修改请求,但是master不在本地需要转发到远程master修改,当远程 修改超过3次则将本地的IDC设成master。 每条记录每次修改都有一个版本号(per-record timeline consisitency),master及YMB可 以保证复制时候的顺序。 Yahoo!的PNUTS实际可理解为master-master模式。 一致性:由于记录都需通过master修改,master再复制到其他IDC, 因此可达到所有IDC 数据具有最终一致性。 可用性: 由于所有IDC都有每条记录的本地数据,应用可以根据策略返回本地cache或最新版 本。 本地修改只要commit到YMB即可认为修改成功。 任一IDC发生故障不影响访问。 论文中提到的其他优点 hosted, notifications, flexible schemas, ordered records, secondary indexes, lowish latency, strong consistency on a single record, scalability, high write rates, reliability, and range queries over a small set of records. 总之,PNUTS可以很好的适合geographic replication模式。 记录publish到本地YMB则认为成功,免除Dynamo方式需要等待多个Data Center返 回的latency。 如果发生master在异地则需要将请求forward到异地,但是由于存在master转移的策 略,需要forward的情况比较少。 极端情况,当record的master不可用时候,实现上似乎有些可疑之处,读者可自行思考。 Under normal operation, if the master copy of a record fails, our system has protocols to fail over to another replica. However, if there are major outages, e.g. the entire region that had the master copy for a record becomes unreachable, updates cannot continue at another replica without potentially violating record-timeline consistency. We will allow applications to indicate, per-table, whether they want updates to continue in the presence of major outages, potentially branching the record timeline. If so, we will provide automatic conflict resolution and notifications thereof. The application will also be able to choose from several conflict resolution policies: e.g., discarding one branch, or merging updates from branches, etc. 初步结论 低带宽网络 PNUTS record-level mastering模式最佳。 高带宽低延迟网络 (1Gbps, Latency < 50ms) 1. 用Dynamo Quorum, vector clock算法实现最终一致性 2. 用Paxos实现强一致性 后记 Resource 1. Ryan Barrett, Transactions Across Datacenters 2. Jeff Dean, Designs, Lessons and Advice from Building Large Distributed Systems (PDF) 3. PNUTS: Yahoo!’s Hosted Data Serving Platform (PDF) 4. Thoughts on Yahoo’s PNUTS distributed database 5. Cassandra – A Decentralized Structured Storage System (PDF) 6. Yahoo!的分布式数据平台PNUTS简介及感悟 7. 8. 2008-12-13 21:57:58 浅谈IDC的流量分析 9. 标签:流量分析 IDC SNMP NETFLOW 端口镜像 10. 版权声明:原创作品,如需转载,请与作者联系。否则将追究法律责任。 11. 1. 背景概述 12. 在上个世纪90年代中期IDC刚刚在国内兴起的时候,IDC的出口带宽还很小,后来 慢慢地从百M扩展到千M,一直快速发展到现在的10G,甚至几十个G,接口类型也从以前的ATM发展到现在的POS。出口带宽越来越大,IDC流量分析的基础组成部分--流量采集技术也随之一直在变化。 13. 在百M和千M出口带宽时代,使用端口镜像技术就可以对IDC的所有出入流量进 行完整的采集,然而进入2.5G/10G/40G接口时代后,端口镜像、探针和旁路监测技术的流量全采集方式无疑部署越来越麻烦,部署的层级需要不断地往下移,需要部署的点越来越多,造成部署成本高昂,这样的流量采集技术目前已经在IDC的实际应用中逐渐被淘汰了。 14. 为了应对巨大流量背景下分析流量的来源和去向及流量的应用类别,设备厂家们提 出了FLOW的概念,像CISCO的NETFLOW,Juniper的CFlowd,HP/NEC/Alcatel/Foundry,Extreme等的sFlow,华为的NETSTREAM等等,尤其是CISCO 的NETFLOW已经在IDC里得到了广泛的应用。 15. 2. 为什么需要流量分析 16. 网管人员在日常的IT管理中,经常都会面临下面的一些情况: 17. 外部流量是从哪里来的? 18. 是否有不友善的攻击行为? 19. 本网的流量都到哪里去了? 20. 如何做实时的细节分析? 21. 本网内各个IP的流量使用情况如何? 22. 是哪些IP地址或是应用层协议造成网络的拥塞? 23. 在我的网络里各种应用层协议的流量比例各是多少? 24. 如何调配多条对外线路间的流量以达到负载均衡 ? 25. 如何预测网络流量的增长,在多久之后需要进行扩建? 26. 流量分析系统就是为了解决这些问题而产生的~~~ 27. 3. IDC流量的采集方式 28. 单纯的从流量数据的采集方式上来看,可以分为SNMP,端口镜像/探针/旁路,FLOW, RMON等几种主要方式,其中SNMP主要应用于设备接口的流量数据采集,如采集某个 交换机端口的流入流出字节数,包数等;端口镜像/探针/旁路主要应用于千兆以下的端口的全流量采集,这种方式下采集的数据可以进行数据包内容的分析,也即现在非常热的所谓的DPI(深度包 检测 工程第三方检测合同工程防雷检测合同植筋拉拔检测方案传感器技术课后答案检测机构通用要求培训 );而各种FLOW技术则是设备按照一定的 采样比进行网络五元组(源IP+源端口+目的IP+目的端口+协议类型)的统计,然后输出统计后的流记录。 29. 从IDC流量的实际应用来说,这几种方式都有其应用的场景,比如SNMP技术采集 到的交换机端口的接口流量可以反映网络内的流量分布和带宽占用情况,同时也可以反映设备的工作状态,如丢包率,错误包率等。而端口镜像/探针/旁路等全流量采集技术则可结合深度包检测技术在自动监测IDC托管的各类网站、论坛是否含有非法、黄色的内容的场合下发挥独特的技术作用。FLOW技术则在IDC的流量流向分析、异常流量分析等应用中独具扩展性。 30. 4. IDC流量的,个关键呈现视图 31. 那么从IDC流量分析的日常需求来看,要想帮助IDC真实地、更好地反映网络内的 流量情况,流量分析系统需要具备以下的,个视图,这,个视图将会分别从不同的角度为IDC准确分析流量提供直观的呈现。 32. 2.1 流量流向视图 33. 流量流向视图主要是结合AS域准确反映本地网络的流量的流向和来源,在这个视 图中,将可以很直观地看出访问本IDC网络的流量主要从哪些省和哪些运营商处来,通过在本省城域网的出口上分析流量,也可以很直观地看出本省的流量主要发送到哪些省和哪些运营商处去了,这些分析数据为IDC托管业务的发展提供了可靠的决策依据。 34. 2.2 子网流量视图 35. 子网流量视图可以很直观地呈现本地网络内的不同子网的流量,通过TOP N分析可 以直观地反映子网的排名情况。 36. 2.3 客户流量视图 37. 客户流量视图是从IDC的客户的角度来呈现网络流量的,可以很直观地呈现出每个 IDC客户的实时流量排名及其应用的流量排名。 38. 2.4 骨干流量视图 39. 骨干流量视图反映的是IDC的骨干网络设备之间的流量分布和带宽占用情况。 40. 2.5 应用流量视图 41. 应用流量视图反映的是IDC托管的应用的流量情况,如WWW,,,,,视频,P2P 等应用的流量分布情况。 42. 2.6 拓扑流量视图 43. 拓扑流量视图反映的是IDC的网络拓扑设备之间的流量分布和带宽占用情况。 44. 2.7 异常流量视图 45. 异常流量视图反映的是IDC的网络异常流量的详细信息,这里可以结合镜像等全流 量采集技术将异常流量的内容抓下来进行分析,方便定位故障。 46. 5. 流量预警模型 47. 由于,,,的网络流量增长迅速,常见的报警阀值式的策略配置在实际应用中意义 不大,有必要建立新的流量预警模型来进行更有效的预警。结合前面的《关于网管软件中的预警功能设计.doc》文章中的内容我们可以知道,基线预警的模型应用在这里是再合适不过了,基线预警的详细内容请参考前文。这里就不做过多的阐述了。 48. 参考:关于网管软件中的预警功能设计.doc 49. 关于网管软件中的预警功能的发展 50. 2008-11-17 11:45:37 51. 标签:网络 故障 网管 IDC 数据中心 52. 版权声明:原创作品,如需转载,请与作者联系。否则将追究法律责任。 53. 我们知道,根据国际标准化组织的定义,网管软件有五大功能,分别是故障管理, 计费管理,配置管理,性能管理和安全管理。当然市场上的产品对这些模块可能是选择性的实现,但是一般来说,故障管理和性能管理是网络管理中的最主要的组成部分,也是各类网管产品都提供的核心功能。故障管理和性能管理功能中最重要的又是故障和性能的预警,一旦预警功能失效,出了真正的故障之后,损失已经造成,虽说亡羊补牢犹未晚,但总不如在故障出现之前,性能下降之前解决问题来的更有价值,损失更小。 54. 预警功能是如此重要,大多数的软件也在这块上下足了功夫,随着对网管的不断深 入的理解,预警策略的配置也越来越灵活,除了报警阀值的自定义配置之外,很多网管产品都加入了报警时段、报警频次、报警方法、报警级别等概念,并可以将这些参数进行灵活的配置,单纯的从技术上来说,这样灵活的配置已经可以让网管人员任意的进行配置了,可以满足几乎所有的应用场合。 55. 然后,随着网管应用的深入,很多网管人员发现这种报警阀值的配置方法太繁琐了, 不进行配置的话网管软件产生的网络事件又太多,从而导致网管软件不能真正帮助网管人员减轻日常网管的工作量,久而久之,网管软件中的预警功能就弃而不用了,庞大的网管软件就变成了一个偶尔用来实时监视的工具和领导来参考的一个门面。于是,各网管厂家开始推出“基线预警阀值配置”的概念,通过这个配置向导可以帮助用户快捷地配置好所有的策略。 56. 然而随着网络的快速发展,网络应用的层出不穷,很快这种预警策略配置的设计方 法变得不再有效。网管人员发现,上个月还有效的预警策略可能在这个月就已经变得无效了。那么如何才能更有效地适应这种应用场景下的预警管理呢,“基线报警”的概念就这样被提出来了,基线报警的核心是通过日基线/周基线/月基线等概念结合一定的算法来动态生成当前的报警阀值,而网管软件本身无须进行相应的报警阀 值配置,大大减轻了网管人员的阀值配置难度,有效地提升了网络事件报警的正确 性。 57. 从上面我们也可以看出,网管软件中的预警配置这个功能从最早的单一阀值配置, 逐步发展到灵活的预警策略配置,再发展到基线预警阀值配置,到现在流行的基线 报警。一步一步地更好地满足了网管中对故障管理和性能管理更有效管理的需求。 如下图所示: 58. 59. 60. 虚拟化IDC包含的业务内容 61. 2011-05-27 13:07:15 62. 标签:VDC 业务内容 虚拟化 IDC 63. 版权声明:原创作品,谢绝转载~否则将追究法律责任。 64. 虚拟化IDC业务就是一系列由供应商向用户提供的资源和资源集合的模版组合。 65. 这些业务模版都是一些资源和资源集合的抽象,用户可以根据自己的需求对这些业务模版进行配置订购。这些业务在经过用户订购以后将会生成的,和真实资源和资源集合 一一对应的,就是业务实例也就是产品。 66. 所有的VDC中的资源包括网络,存储,计算能力以及应用业务,都需要以业务的形 式向用户提供。任何VDC资源都可以按单个或多个有机整合的方式发布为VDC业务。一个 完整的业务需要以下属性和内容:业务名称,业务编码,业务属性,业务权限,业务版本,业务费用,资源关联,业务内容关联(可选),部署信息,策略信息,SLA。 67. 68. 一、VPS 69. VPS(VirtualPrivateServer)是通过云计算技术将存储、硬件和网络等资源统一虚拟化为相应的资源池,从资源池分割成多个虚拟专享服务器的优质服务。每个VPS都可 分配独立公网IP地址、独立操作系统、独立超大空间、独立内存、独立CPU资源、独立执行程序和独立系统配置等。 70. 面向客户群:中小企业、政府、企事业单位。 71. 二、弹性云主机 72. 弹性计算业务是一种按需分配计算资源的云计算服务。弹性计算业务提供了一系列不同规格的计算资源。这些规格参数包括:CPU性能、内存、操作系统、磁盘、网络。不 同规格的计算资源有不同的价格。用户可以根据需要申请不同规格的计算资源。 73. 针对客户的突发性、临时性的大量计算和存储资源需求,为企业客户提供一个虚拟的弹性计算集群环境,实现用户动态的扩展或者缩减服务配置(CPU,内存,存储)以及 增加或者删减弹性虚拟主机数量。 74. 完全采用动态分配管理,是项目或者事件形式促发整个系统的一种行为。能高效、迅速的调度资源,对系统的计算资源进行有效整合,使之可以应对客户业务的弹性需求。 75. 面向客户群:媒体、网络游戏开发商、中小型软件开发商、应用软件开发商、高校及科研院所。 76. 三、云终端 77. 云终端是一种低成本、免升级、易管理、便操作、强安全、高可靠的瘦终端型客户机,配合VDC云计算和云存储产品形成“终端+网络+应用”的组合型服务。能有效降低采 购及运营成本。 78. 对于云终端: 79. Ø 满足可控的移动存储设备等外接口; 80. Ø 实现集中管理、单独授权的应用模式; 81. Ø 实现统一部署的操作系统和升级维护管理。 82. 面向客户群:金融、证券、教育等需要大量客户端的统一服务平台(如呼叫中心)、联通自身营业厅。 83. 四、在线云存储 84. 在线云存储通过云存储技术,整合并高效调度存储资源,满足客户的弹性使用需求。云存储不仅仅是一个硬件,而是一个由网络设备、存储设备、服务器、应用软件、公用 访问接口、接入网和客户端程序等多个部分组成的系统。 85. 在线云存储业务满足集团型企业的容灾备份业务需求;支持多种应用方式,如云备份、云数据共享、云资源服务等,也提供标准化的接口供其他网络服务使用,能按照访问 就近原则,地理位置越近,实体之间数据传输的效率越高、成本越低。 86. 在线云存储业务能够采用集中存储与分布式存储相结合。能实现根据客户的实际需要进行调整存储的大小,并提供相应的灾备业务。 87. 面向客户群:对成本敏感、数据安全要求高、服务数据不中断的中小企业。 88. IDC目前存在的问题和发展趋势 89. 2011-05-26 11:33:22 90. 标签:虚拟化 IDC 91. 版权声明:原创作品,谢绝转载~否则将追究法律责任。 92. 一、目前数据中心在运营方面面临着一些问题: 93. 1) 数据中心机房空间资源有限,高低端机房发展不均衡; 94. 高端机房空间有限,机房占用率为75,,机柜占用率为76,,网络出口等资源不足,机架电力供应紧张;部分低端机房产能过剩,地区业务发展不均衡; 95. 2) 硬件资源利用率较低,建设运营成本较高; 96. 传统IDC服务器计算和存储资源平均利用率不足10%,Opex-电费占比最高(28%)、Capex-电源和空调的投资占比最大(50%); 97. 3) 业务结构单一,未形成整合优势: 98. 传统IDC以主机托管业务为主,机房较为分散,每平米单位资源收益率不高,正处于服务型产品转型发展的初级阶段; 99. 4) 业务竞争和技术发展压力大: 100. 当前IDC市场竞争激烈,由于各大IT巨头和各种IDC服务厂商的介入,让利润本来很薄的市场更加难做,同时市场对更低成本和差异化的资源出租型业务的需求越来越多。 101. 二、 IDC的发展趋势 102. 在信息化和3G移动互联网刚性需求的带动下,2009年中国IDC市场总体规模为66亿元人民币。然而,目前IDC产业存在的弊端阻碍了其进一步发展:在市场方面,同质、 低价、低水平的无序竞争导致运营商被有意无意地管道化,端到端的网络能力没有充分利用;在业务方面,IDC业务结构单一,业务增长主要由投资带动,缺少增值业务,以主机托管业务为主,缺少主机租赁业务,不利于商业模式的演进和新业务的展开;在资源方面,IDC资源布局松散,缺乏面向新业务的有效整合,基础资源的平均利用率低,建设成本和运营成本较高;在技术方面,运营商面临从全网的角度,对终端用户与信息源的互访质量进行优化。 103. 据麦肯锡公司估计,全球的数据中心在技术基础架构和服务方面的开支每年超过3500亿美元,其中一半是资本开支(产品),一半是运营开销(服务和人工)。此外,估 计有70%或更多的开销用于维护现有的基础架构,只剩下30%或更少的开支用在能够使企业在业务差异化方面实现突破的新技术和新应用的开发上。另据估计,数据中心虚拟化和私有云技术的市场规模到2015年大约为850亿美元,占整个数据中心市场的20%。据预测,2010年我国IDC数据中心的市场规模将达到100亿元。我国IDC发展势头正猛,市场前景一片大好,但目前我国IDC所提供的服务水平,距离真正的国际标准还存在着一定的差距,企业用户仍然表现出诸多不满,例如:安全性差、经常宕机、资源没有保障、价格昂贵等原因。 104. 传统的IT数据中心,资源利用率较低,服务器数量增长、电源能耗与温度控制、网络设备扩充不仅使管理难度增大,也令IDC的硬件成本在无法控制地增加。因此IDC的 管理运维成本很高,HA集群及负载均衡规划也相对孤立,如何将IDC所有资源进行统一整合,最大程度发挥资源效能,并同时进行集群、备份的整体部署,都需要IDC利用新技术做出改变。 105. 为实现统一规划基础架构、极大降低运维支出的目标而迫切需要改变IDC的传统建设方式。采用云计算等新技术,新型的数据中心能实现节能减排、绿色IT管理,并将具 备高度灵活性及自我管理和自我修复能力。新型数据中心的建设既符合国情发展策略,也 符合IDC运营商的长久利益。随着运营商市场竞争的加剧,以及用户对IT技术的充分依赖,电信运营商可结合自身在网络、安全及运营方面的专长,满足客户对于云计算服务的需要,同时提高资源的利用率,拓展新的市场空间,创新业务模式。 106. IDC机房设备变更流程 107. 2011-01-12 16:03:57 108. 标签:IDC 机房设备变更流程 IDC机房 109. 原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。 110. 这是之前在IDC部门写一个设备变更流程,贴出来跟大家共享,如看不清楚图,直接双击就能看到清晰点图片,还有哪里需改进请指点一下,谢谢~ 111.
本文档为【IDC机房的维护与运行】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
下载需要: 免费 已有0 人下载
最新资料
资料动态
专题动态
is_574951
暂无简介~
格式:doc
大小:59KB
软件:Word
页数:28
分类:工学
上传时间:2018-12-22
浏览量:16