随笔- 23  文章- 0  评论- 9 
2007年12月30日
柯维 高效能人士的7个习惯【专题节目】

最近在看这本书，推荐一下

 

http://www.youku.com/playlist_show/id_950512.html

posted @ 2008-07-13 18:33 加菲猫 阅读(22) | 评论 (0) | 编辑
Firefox IE 自动代理脚本

我的笔记本在办公室需要代理上网，而家里不需要，每次都需要更改配置。

于是写了一个脚本:

function FindProxyForURL(url, host)
{
   //if (!isResolvable("xxx.mycomany.com"))
    // return "DIRECT";

   if (isInNet(myIpAddress(),"192.168.1.0", "255.255.255.0"))
      return "DIRECT";

      return "PROXY 172.19.28.42:8080";
}

假如本地ip地址是 192.168.1.XXX 则是在家直连上网，否则使用公司的代理服务器

保存成文件。

image

在Firefox或者IE配置一下就可以了

image

结果发现firefox判断本地ip地址你那里有问题。找了下资料，原来是 myIpAddress() 函数返回了ipv6格式的地址，配置一下firefox , 在地址栏输入 about:config ,修改 network.dns.disableIPv6 为 ture . 问题解决了！

posted @ 2008-07-07 21:44 加菲猫 阅读(46) | 评论 (0) | 编辑
几种笔记软件的使用感想

大家平常都会记笔记，我也用过不少笔记软件了，写一下感觉(并非评测啊)

  • MyBase

以前用的一直是 MyBase ，感觉比较完美。也是我购买的第一个正版软件，不过也有下面的问题:

1. 代码着色有问题，以前还有个代码加亮插件。现在都找不到了

2. 不同机器的同步只能通过拷贝文件来同步，加上办公室的电脑，我有两台台式机和两台笔记本，同步太麻烦（作者提供B/S的版本，不过还得自己有服务器，而且第一感觉不是很好用)

我现在是使用公文包配合 MyBase在用。麻烦

 

  • Google Notebook

软件不错，通过笔记本, 段落，tag来组织笔记，可以全文搜索，很不错。现在用的很多

问题主要是有点慢，有时候莫名其妙的打不开(GFW?) 而且图片插入很麻烦，几乎不能做

代码着色的功能可以通过live writer 着色，拷贝的方法解决

 

  • EverNote

这个软件是国外有名的软件，现在的版本支持中文也没有问题了。准备拿到帐号就正式用它，希望会一直免费

用了还不错，笔记的使用方法和 google notebook 很像，插入图片等都没有问题

代码着色通过些麻烦的方法也可以做到，live writer 着色，拷贝到 EverNote

最出色的是3.0版本其实后端是一个web service , 就是说这个软件相当于带了客户端的 google notebook! 更换机器也没有问题。而且可以方便的插入图片和手绘!

软件很好很强大，但是问题也很难容忍：

1. 中文搜索，有问题

2. 经常 EverNote.exe 进程挂死，特别是操作系统从休眠中醒来的时候。占CPU100%，而且还杀不掉。只能按Reset重启机器。

而且软件也大了点 >50MB

 

  • WikiPad

采用Wiki的方式来组织笔记，很新颖，虽然用Wiki有段日子，但是作为客户机软件还是用不惯

只能插入互联网上已有的图片，而且假如把代码拷贝进去，代码按照wiki解析，有不少麻烦，可能我还不太会用

 

一个不需要web server的wiki程序，整个程序就是一个 html 页面，每次写了拷贝了就可以带走，适合放在U盘。不过缺点也和WikiPad有些像。而且还没有WikiPad好用

 

  • Zoho

一个在线office，试用了一下功能比 Google Office 还多，想尝鲜的筒子可以看看。

网上的介绍：ZOHO是AdventNet公司开发的一个办公室软件套装，它完全可以被认为是市场上最具竞争力且功能最完全的网络办公套件，绝对是这个领域的佼佼者，比起Google文件可谓有过之而无不及。

个人推荐Zoho的个人Wiki功能，还不错。比一些其他的托管Wiki好用。

不过他的笔记和文档都有些用不惯，而且速度不快，我还是继续用Google吧

 
posted @ 2008-06-09 14:35 加菲猫 阅读(152) | 评论 (1) | 编辑
CHM 帮助文件乱码不完全解决方案

　　经常碰到一些 CHM 格式的帮助文档出现乱码无法阅读的情况，而且 CHM 文档不像浏览器一样，右键可以选择字符编码，非常不便。究其原因，主要就是 CHM 文档在页面中没有指定合适的字符编码所致。
CHM 的实质是 HTML 文件。一般情况下没有指定字符编码的 CHM 是调用 Internet Explorer 浏览器的字符编码设定来显示 CHM 文件的。
　　在注册表 HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\International 下有 AutoDetect 和 Default_CodePage 2个键名，就是 IE 浏览器字符编码的相关设定键。

　　因此，我们在简体中文的操作系统上打开简体中文的 CHM 文档出现乱码时，把 AutoDetect 设置为1就能正常显示；在简体中文的操作系统上打开繁体中文的 CHM 文档出现乱码时，先把 AutoDetect 设置为0，然后把 Default_CodePage 设置为 BIG5 的代码页 950 即可。
　　简体中文Windows常用 ANSI 代码页936，在注册表二进制值是 A8 03 00 00；
　　繁体中文Windows常用 ANSI 代码页950，在注册表二进制值是 B6 03 00 00；
　　拉丁语系Windows常用 ANSI 代码页1252，在注册表二进制值是 E4 04 00 00。

 

上文是转贴自 http://hagengoo.blogspot.com/2007/04/chm.html

一个正常的chm源代码常常是这样：

<HTML>
<HEAD><META http-equiv="Content-Type" content="text/html; charset=gb2312">

有些chm没有 charset 字段，所以就出问题了，比如

我安装的是英文系统

Universal Alphabet (UTF-8) utf-8 65001 E9 FD 00 00

 

附带解决问题的注册表脚本

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\International]

"Default_CodePage"=hex:a8,03,00,00

posted @ 2008-06-02 00:08 加菲猫 阅读(166) | 评论 (0) | 编辑
MTBF

以下笔记参考多篇资料：

MTBF（Mean Time Before Failure，平均失效间隔时间）是指一个可修复系统失效的平均间隔时间，MTBF越大，这个系统就越可靠。

产品故障少的就是可靠性高，产品的故障总数与寿命单位总数之比叫“故障率”（Failure rate），常用λ表示。例如正在运行中的100只硬碟，一年之内出了2次故障，则每个硬碟的故障率为0.02次/年。当产品的寿命服从指数分布时，其故障率的倒数就叫做平均故障间隔时间（Mean Time Between Failures），简称MTBF。即：

MTBF=1/λ

这个数字是怎么得出来的呢？不同厂商有不同厂商的做法。

WD采用的是多台驱动器同时工作的累计方式，如1000台驱动器同时工作1000个小时，若容许故障率（AFR）定于某规定数值（如0.7%），平均无故障工作时间即为100万小时（1000×1000）。具体到WD Caviar RE2的120万小时平均无故障工作时间，则是在1200台驱动器以100%的负载循环（读/写各占50%）同时工作1000小时、7×24开机的情况下，容许故障率低于0.7%而得到的。1000小时相当于1个多月的时间，是完全可行而不会影响产品的正常生产和上市的。

一年8760小时。120万小时约为137年，并不是说该种硬碟每只均能工作137年不出故障。由MTBF=1/λ可知λ=1/MTBF=1/137年，即该硬碟的平均年故障率约为0.7%，一年内，平均1000只硬碟有7只会出故障。

根据业界一些实际的测量，MTBF的数字是完全靠不住的。厂商的MTBF数据都有其特定的测试环境和条件，而且厂商对于disk error的错误和用户也不一致，常常一个硬盘到了厂商那里检测却报告说没有什么问题。

一般来说，年均故障率可以参考以下的数字：

While drive manufacturers often quote yearly failure rates below 2% [2], user studies have seen rates as high as 6% .

posted @ 2008-05-22 00:04 加菲猫 阅读(48) | 评论 (0) | 编辑
接受电话面试

我是搞streaming server的，最近一直在面试别人。不过周日有公司电话面试了我，虽然因为一些原因我应该不会过去(工资高出大截还是可以考虑的吼吼)，不过我觉得面试也是一个检验自己的机会，对于工作而言，在特定的时间需要的知识是比较狭窄的。同行业公司的面试，可以看看自己的知识结构是否有需要加强的地方。

首先都是一些基本的问题，首先是linux下的一些操作，我发现自己虽然经常trace现场和sit的问题，但是某些操作还是不是很熟悉，比如和用户权限的操作，因为大部分时候都是用root，这方面的知识可以说很少。说开去，(他们没有问)对于Linux/Unix的用户权限模型也是一知半解，需要系统的看一遍《UNIX环境高级编程》那本书。

然后网络方面的一些基础知识，我自认为在TCP/IP编程方面还是不错的，也解决过很多的性能和环境问题，一些OPTION参数很了解，一些7层协议比如FTP什么的问题我还答得不错，但是这次面试还是发现了一些问题，比如子网段的地址没有算对，我考这个太基本了。对于组播的地址等也不熟悉，以前看《TCP/IP详解》第一卷，光看TCP的实现了，其他的一些更加基础的东西必须可以记得更牢才行。

他们居然还问了RAID方面的一些东西，不过我们的文件系统是自己做的，说句实话RAID理论很清楚，他问了一些硬件RAID设备的知识，回答是否正确我就不知道了。

然后问了RTSP/RTP协议的一些东西，这些是做streaming的基础，我虽然不做这块，但是看来是需要加强的。

MPEG知识的话，我基本为0，其实手上还是有些不错的资料的，得好好看看，虽然streaming server只需要发发包，编解码的不要太管，但是一些系统层的要知道点。居然还问到 RTP vs TS ， 呵呵。

他们还问了一些solaris的问题，太过底层了，没有搞过，这个答不上来也就罢了。

觉得需要加强的地方：

1. 毕竟没有系统的学习过linux/unix编程，虽然掌握了不少的高级技巧，但是某些基本的地方还不够扎实

2. 网络而言，TCP/UDP的编程差不多了，但是一些基本的子网的知识需要加强一下，总之第一卷要看仔细

3. MPEG / RTSP / RTP 需要多知道点，弱项啊

4. 一些高级技术，比如32位系统访问超过4G内存的，我只是知道是LVM(不是卷管理的那个)，技术细节还不清楚啊！我也奇怪他们的开发怎么搞的这么杂？
-------------------------
后记：隔了很久没有下文，以为我被刷掉了，虽然开始只是应做猎头的朋友之情去面一下，但是被刷还是难免有些打击自尊心。不过前天又再次电话过来，原来只是流程较慢而已:>
可惜，最近的诱惑太多太大，该公司虽然还算不错，还是拒绝吧

posted @ 2008-03-10 23:50 加菲猫 阅读(68) | 评论 (0) | 编辑
Content Networking - 1.3.Purpose and Goals

 

读书笔记： 《Content Networking Fundamentals》

在生活的各个方面，需求导致新的创造和发明，网络计算也是一样，它的发展伴随着不断增长的用户需求：更加丰富的内容，更多的带宽，更多的可靠性。要完成这些要求，首先你必须解决以下四个方面：

Scalability and Availability

Bandwidth and Response Times

Customization and Prioritization

Security, Auditing, and Monitoring

Scalability and Availability

Scaling the Application

content networking 可以为应用提供未来增长的可扩展空间，而不需要改变应用工作的方式，只需要微小的改变网络架构。包括以下的服务：

  • Content edge delivery Positioning application content away from the origin server, and in closer proximity to clients, scales the application by offloading requests to the content network. 将内容放在更加接近用户的地方。

  • Enhanced content delivery with IP multicast, stream-splitting, and resource reservation IP multicast and stream-splitting scales the network by avoiding replication of identical flows over the same network link, thus minimizing end-to-end bandwidth consumption of content delivered to a large number of users. Resource reservation scales the application by manipulating network parameters to expedite application traffic delivery.通过组播和流分割技术，避免通过同样的网络连接（？)复制同样的内容，这样最小化了大量用户的端到端的带宽消耗。资源预留可以加快应用的通信传输。

  • Content transformation and prioritization Transformation provides conversion of content within the network without further burdening of origin servers. Prioritization enables custom network delivery of application traffic.

  • Flash crowd protection Protection against sudden, but valid, traffic spikes directed toward an application is important to maintaining service levels to customers. 需要在突发的大流量下维持服务水平。

 

Increasing Application Availability

包括以下部分：

  • Content switching Increases availability by replicating origin server content across numerous identical systems, either within the same data center or across globally distributed data centers. 在多个相同系统复制原始服务器的内容，他们可以在同一个数据中心或者是跨全球的数据中心

  • Session redundancy Session redundancy provides failover from one network device, such as a firewall or load balancer, to an identical device without dropping existing TCP connections. 在网络设备(firewall or LB)失效切换的时候不丢失已有的tcp连接。

  • Router redundancy Protocols, such as Hot Standby Router Protocol (HSRP) and Virtual Router Redundancy Protocol (VRRP), provide router gateway redundancy by having two routers or load balancers share a virtual IP (VIP) and MAC address for clients to use as their default gateway. If either fails, the other will take over within seconds.

  • IP routing redundancy Dynamic IP routing protocols, such as OSPF, EIGRP, and IS-IS, provide availability within a routing domain by maintaining multiple paths to each network in the routing table.

  • Layer 2 switching redundancy Spanning tree and Cisco Etherchannel provides Layer 2 redundancy in a switched environment.

posted @ 2008-02-24 22:08 加菲猫 阅读(82) | 评论 (0) | 编辑
Content Networking - 1.1 概念

读书笔记： 《Content Networking Fundamentals》

从下面的内容里面，我感觉Content Networking总的概念就是，对于传统的基于包交换的网络，传输层是完全内容无关的，内容的感知是内容产生者的责任，Content Networking 就是对于整个网络层次，都是内容感知（content-awareness）的。

内容网络涵盖了网络处理各方面的元素，从下面的图片，我们可以看到3个层次：

Originator：内容生产者（or an origin server）为clients请求提供内容, 内容可以是live video, 文件下载传输还有动态的静态的数据，交互式多媒体内容。应用包括e-learning, corporate communications, e-commerce, hosting services, and enterprise client/server applications, among many others.

Network infrastructure：这层分发content, 包括一些协议和概念，such as TCP/IP and Ethernet, plus the content networking services and intelligent network services discussed in this book.

Recipient：请求content的client，可以是PC桌面软件不如浏览器，视频播放器等，也可以是TV/PDA/IP Phone等。

图片：Relationship Between Recipient, Network, and Originator Content Network Entities

image

传统的网络是基于包交换的，Originator 和 Recipient 之间互相所知的很少，除了一些name service等信息。基本上，过去的网络设备都是和应用无关的，最近几年，认识到网络增值应用中新的和日益增加的需求，不断加入新的网络软件来实现内容网络技术。满满的，现有的网络设备不断的扩展性的应用协议和智能网应用服务。也产生了新的基于内容的设备。

内容的网络化，可以大致的定义为不仅仅是内容的Originator是内容感知（content-awareness）的，而是网络的3个层面都是内容感知的。其实一般来说，Content Networking是一个有些模糊的概念。

posted @ 2008-02-24 16:43 加菲猫 阅读(38) | 评论 (0) | 编辑
RAID , LVM and EVMS

(一)数据丢失的原因：

  1. 有意或者无意的数据删除，除了定期备份，谁都救不了你
  2. 常规的系统破坏，操作系统数据库的bug都能导致这些问题，数据会慢慢退化，数据备份都不能解决这个问题。
  3. 磁盘驱动器完全失效，RAID的冗余可以保护这种问题
  4. 掉电导致数据一致性问题，从而丢失数据。RAID帮不了你，需要使用日志(Journaling)文件系统或者日志数据服务器来防止丢失数据。
  5. 磁盘驱动器坏块。

磁盘驱动器上缓慢但持久的存储块丢失是造成磁盘驱动器失效的常见形式。导致存储块丢失主要有以下几种因素：
◆ 显微镜下可见的尘埃粘在盘片上；
◆ 磁头敲击盘片时留下的沟痕；
◆ 磁介质在制造时做得太薄；
◆ 与磁头长期接触导致盘片老化等。

随着坏块的积累，数据块就会出错。硬盘驱动器检测到错误块后，会自动从磁盘其它地方找一块新的数据块分配，直到有一天硬盘上的坏块查找表被填满，Linux接近停滞状态，同时log里面有“status=0x51 { DriveReady SeekComplete UnrecoverableError }”信息。尽管这可能是最常见的磁盘出错情况，但几乎没有一个解决方案能处理好这一问题，RAID当然也不能。

此外，硬件故障、电缆连接，甚至环境噪声等问题也会引起数据破坏。

(二)LVM


LVM 是 Logical Volume Manager（逻辑卷管理）的简写，它由 Heinz Mauelshagen 在 Linux 2.4 内
核上实现。
与传统的磁盘与分区相比，LVM 为计算机提供了更高层次的磁盘存储。它使系统管理员可以更方便的为应用与用户分配存储空间。在 LVM 管理下的存储卷可以按需要随时改变大小与移除（可能需对文件系统工具进行升级）。LVM 也允许按用户组对存储卷进行管理，允许管理员用更直观的名称（如“sales”、“development”）代替物理磁盘名（如 “sda”、“sdb”）来标识存储卷。
1. 为什么使用LVM?
LVM 通常用于装备有大量磁盘的系统，但它同样适于仅有一、两块硬盘的小系统。
4.1.2.1 小系统使用LVM 的益处
传统的文件系统是基于分区的，一个文件系统对应一个分区。这种方式比较直观，但不易改变：
1、 不同的分区相对独立，无相互联系，各分区空间很容易利用不平衡，空间不能充分利用。
2、 当一个文件系统或分区已满时，无法对其扩充，只能重新分区、建立文件系统；或把分区中的数据移到另一个更大的分区中；或采用符号连接的方式使用其它分区的空间，非常麻烦。
3、 如果要把硬盘上的多个分区合并在一起使用，只能采用再分区的方式，这个过程需要数据的备份与恢复。
当采用 LVM 时，情况有所不同：
1、 硬盘的多个分区由 LVM 统一为卷组管理，可以方便的加入或移走分区以扩大或减小卷组的可用容量，硬盘空间被充分利用。
2、 文件系统建立在逻辑卷上，而逻辑卷可在卷组容量范围内根据需要改变大小。
3、 文件系统建立在 LVM 上，可以跨分区，方便使用。

下面是结构图：

image

卷组（VG）   ：volume group
LVM 中最高抽象层，由一个或多个物理卷所组成的存储器池。
物理卷（PV） ：physical volume
典型的物理卷是硬盘分区，也可以是整个硬盘或已创建的软件 RAID 设备。
逻辑卷（LV）  ：logical volume
相当于非 LVM 系统中的分区，它在卷组上建立，是一个标准的块设备，可以在其上建立文件系
统。
物理块（PE） ：physical extent
物理卷以大小相等的 “块” 为单位存储，块的大小与卷组中逻辑卷块的大小相同。
逻辑块（LE） ：logical extent
逻辑卷以 “块” 为单位存储，在同一卷组中的所有逻辑卷的块大小是相同的。

在建立逻辑卷时，可以选择逻辑块与物理块映射的策略：线性映射, 或者交错模式(条带化,相当于RAID0)

(三)EVMS

下表列出了EVMS 中的常用术语。
扇区 块设备寻址的最低级别，它与在其它管理系统中所看到的标准含义一致。
存储对象 EVMS 中的所有存储结构，它能形成块设备，是一系列规则的扇区。
逻辑磁盘 一系列表现为物理设备的规则的相邻扇区。
磁盘段 一系列存在于逻辑磁盘或其它磁盘段的自然相邻的规则扇区。一个段的普通类推应是一个传统的磁盘分区，如 DOS 或 OS/2。
存储区域 一系列逻辑上相邻的规则扇区（没必要自然连续）。基本映射可以成为逻辑磁盘、段或其它区域。Linux LVM 和 AIX LVM LVs，以及 MD 设备，表现为 EVMS 中的区域。
存储容器 存储对象的集合。存储容器提供从这个集合到容器输出的一系列新存储对象的重映射。一个存储容器的适当类推应是卷组，如： AIX LVM和 Linux LVM 中的卷组。但是，EVMS 容器不限制任何重新映射模式，这与在 LVM 或 AIX 中的卷组的情况一样。重映射是完全随意的。
特征对象 通过对 EVMS 本地特征的使用，将一个或多个磁盘、段、区或者其它性能对象创建为一个逻辑上连续的地址空间。
EVMS 逻辑卷 一个可安装的存储对象。EVMS 卷包括基本对象的末尾处的元数据，并且至少有一个静态名称和静态从号。EVMS 中的任何对象都可以转换为一个 EVMS 卷。
兼容性逻辑卷 一个不包括 EVMS 本地元数据的、可安装的存储对象。许多 EVMS 的插件提供对其它卷管理模式兼容性的支持。由于特指为 “兼容性” 的卷不包括任何 EVMS 本地元数据，则它一定是向后兼容至特殊模式。所有磁盘、段或区可以成为一个兼容性卷。但是，性能对象不能成为兼容性卷，只能成为 EVMS 卷。

目前，EVMS 中有三个特征。

第一个特征是驱动器连接。该插件允许任何数量的对象线性的连接到单个对象中。
第二个特征是不良（存储）块重定位（BBR）。BBR 监控其 I/O 路径并探测写入故障（这可能由受损磁盘导致的）。发生这样的故障时，该请求中的数据保存在一个新的位置。BBR 保留重映射的轨迹，并且在此位置保留改变其路径到新位置的所有附加的 I/O。
第三个特征是快照。快照提供了一种机制，不必使卷处于脱机状态就可立即创建一个卷的 “冻结” 副本。这十分有助于完成运行系统中的备份。所有卷都有快照过程（EVMS 或兼容性），并可以利用其它所有可用的对象作为一个辅助存储器。创建快照之后， “原始” 卷的写入导致该位置的原始内容被复制到快照的储存对象中。所以，保存在快照卷中的 I/O 如同来自于快照创建时的原始卷中。

posted @ 2008-02-01 23:34 加菲猫 阅读(142) | 评论 (0) | 编辑
RAID4 in WAFL

因为NetApp的WAFL文件系统使用RAID4的关系，坊间流传RAID4的性能相比RAID5更好，特别是大块的写操作。其实 WAFL使用RAID4是因为更加容易扩充磁盘，因为RAID4专门使用一块磁盘作为校验盘。假如是5块磁盘做RAID5，那么扩充的时候只能再扩5块，而不能是1块-4块。

理论上来讲，RAID4的小块写性能和RAID5有差距，因为单独的校验磁盘是瓶颈。大块的写，它们的性能应该差不多。具体产品的性能和产品本身关系很大，A厂商的Raid4和B厂商的Raid5产品的比较难以说明RAID4/5本身之间的差别。

WAFL文件系统在设计的时候就考虑到RAID的因素，尽量将数据一次写入同一个条带，所以有较好的写性能。

posted @ 2008-02-01 22:01 加菲猫 阅读(37) | 评论 (0) | 编辑
网络存储导论第15章：Netapp产品分析
  1. (连载)网络存储导论第15章：Netapp产品分析(1)(2006-04-24 10:07:47)
  2. (连载)网络存储导论第15章：Netapp产品分析(2)(2006-04-25 10:50:24)
  3. (连载)网络存储导论第15章：Netapp产品分析(3)(2006-04-27 11:25:53)
  4. (连载)网络存储导论第15章：Netapp产品分析(4)(2006-04-28 10:27:20)
  5. (连载)网络存储导论第15章：Netapp产品分析(5)(2006-04-29 11:31:40)
  6. (连载)网络存储导论第15章：Netapp产品分析(6)(2006-05-22 10:26:17)
  7. (连载)网络存储导论第15章：Netapp产品分析(7)(2006-06-12 11:43:11)
  8. (连载)网络存储导论第15章：Netapp产品分析(8)(2006-06-14 11:46:12)
  9. (连载)网络存储导论第15章：Netapp产品分析(9)(2006-06-15 15:09:40)
  10. (连载)网络存储导论第15章：Netapp产品分析-10(2006-06-19 15:05:52)
posted @ 2008-02-01 00:37 加菲猫 阅读(40) | 评论 (0) | 编辑
NetApp的WAFL文件系统对RAID的写优化

 

参考资料：SAN 存储区域网络 / File System Design for an NFS File Server Appliance

 

一.  如何优化RAID4/5的写性能

RAID4/5都有写性能低下的问题，因为涉及到校验数据的处理。但是，一次写操作尽量写入一个分条(stripe)中尽量多的分块(block)，可以优化写性能。

image

上图显示了一个带有4个成员磁盘阵列的读、修改和写的周期，其中一个磁盘包含分条的校验数据。

当新的数据被写入一个独立访问阵列时，将使用下列过程更新校验数据和写入新数据：

  1. 从主机 I/O 控制器接收 I/O 请求和新数据。
  2. 读出将被替代分块的原有数据。
  3. 读出该块的校验数据。
  4. 对校验数据与原有数据实施XOR操作，去除原有数据对校验数据的贡献。
  5. 对该校验数据与新数据实施XOR操作，得到新的校验数据。
  6. 将新的校验数据写入磁盘。
  7. 将新数据写入磁盘。

这个过程称为读、修改和写周期。

在一个读、修改和写周期中，一次单个驱动器的写操作需要独立访问阵列做4次数据传输，即原有数据读出、校验数据读出、新校验数据写入以及新数据写入，这导致单个I / O请求的大量的开销。

因为读、修改和写周期的开销，所以独立访问阵列的读操作比其写操作快得多。事实上，独立访问阵列的写速度比单个磁盘的写操作更慢，也比并行访问阵列的写慢。由于这个原因，当独立访问阵列用于读操作比例大于写操作的应用时，它应该配以回写缓存。

上面是对分条中的少量分块的写操作，假如是对分条的所有分块做写操作，可以直接XOR校验并写入数据盘和校验盘。这样可以大大提高写性能。

假如对分条中一半以上的块做写操作，那么可以：

  1. 为即将要写的若干分块保存新的数据。
  2. 从不被更新的一些分块中读出现存的数据。
  3. 计算新的校验数据。
  4. 写新的分块数据和新的校验数据。

一个回写算法的磁盘缓存可以保存磁盘写，使单个操作能够写入更多的分块。

 

二. WAFL文件系统对RAID写操作的优化

WAFL是广泛用于NetApp存储缓存设备的文件系统，WAFL名称的本意是Write Anywhere File Layout。这种设计可以让WAFL尽量将多个写入块写入操作调度到同一个RAID条带中，避免对一个条带的单块写入，来提高RAID的写性能。

WAFL文件系统的meta-data是存储在文件中的(很多文件系统存储meta-data在磁盘的固定位置)，WAFL有3个meta-data文件:

  1. inde file - contains the inodes for the file system
  2. block map file - identifies free blocks
  3. inode map file - identifies free inodes

将meta-data存储在文件可以让WAFL将meta-data写入到磁盘的任意位置，便于WAFL来优化写操作。

posted @ 2008-01-30 22:58 加菲猫 阅读(59) | 评论 (0) | 编辑
radware-APSolute应用前端解决方案-全局负载均衡解决方案

AppDirector是radware - WSD 产品的下一代，现在转贴一下基于它的radware GSLB方案:

http://www.radware.com.cn/content/solutions/appdirector_global/appdirector_global_1.asp

1. 需求分析

无论用户的数据中心内部采用多么完善的冗余机制、安全防范工具以及先进的负载均衡技术，单个数据中心的运行方式仍然不能保证关键业务可以7*24不间断运行。

而为了满足处于全球范围内不同地点的用户在访问应用时可以具备相同的快速访问感受，单一的数据中心却完法实现。

基于以上两个最主要的原因，用户通过在不同物理位置构建多个数据中心的方式已经成为用户的必然选择。

然而，在构建了多个数据中心后，如何通过有效手段实现多个数据中心间的协调工作，引导用户访问最优的站点，或者当某个站点出现灾难性故障后使用户仍然可以访问其他站点上的关键业务等问题成为用户最关注的问题。

2. Radware 全局负载均衡解决方案

Radware 的全局负载均衡解决方案能够帮助客户通过将相同服务内容布署在处于不同物理地点的多个数据中心中得到更高的可用性、性能、以及更加经济和无懈可击的安全性，以便在全球范围内的客户获得更快的响应时间。

Radware的全局负载均衡解决方案支持 Radware 下一代 APSolute OS 软件体系结构的全部功能，彻底解决了网络可用性、性能和安全问题，使得应用在多个数据中心中获得更高的灵敏并具有自适应性。配合Radware 的高速度、高容量 ASIC芯片+NP处理器的专用硬件应用交换设备，可有效保障网络应用的高可用性、提升网络性能，加强安全性，全面提升IT服务器等网络基础设施的升值潜力。

结合Radware多年来在智能应用流量管理领域的经验，以及对用户实际需求的分析，我们认为负载均衡器应具备如下功能：

  • 能够通过唯一的IP地址或域名的方式作为所有提供相同服务的数据中心的逻辑入口点。
  • 全局负载均衡交换机具有灵活的流量分配算法与机制，以确保用户总能访问可以为其提供最优服务的数据中心的内容。
  • 通过部署高性能的负载均衡产品，能够及时发现各数据中心或数据中心内部的服务器的健康状况，当某个数据中心出现故障时，保证把后续用户的访问导向到正常运行的数据中心上。
  • 针对基于会话的业务，可以提供多种会话保持机制，确保用户在处理业务时的连续性。避免将用户的相同会话的业务请求，分配到不同的数据中心而造成访问失败。
  • 应具备安全过虑及防DOS/DDOS的功能，为服务器提供多一层安全保障
  • 具有很好的升级与可扩展性，能够适应特定的和不断变化的业务需求。

2.1 方案拓扑图

2.2 AppDirector-Global实现全局及本地负载均衡

在全局及本地负载均衡方面，AppDirector-Global主要在网络中实现以下功能：

2.2.1 全局负载均衡策略

Radware支持多种全局负载均衡策略，能够通过唯一的IP地址或域名的方式作为所有提供相同服务的数据中心的逻辑入口点。根据用户的实际情况，可以选择其中以下的一种，也可以组合同时使用。

方式一 基于DNS 重定向
支持基于Local DNS位置的就近性解析功能。当用户通过域名方式进行访问时，可以根据用户使用的Local DNS位置进行就近性计算，将最佳站点的IP地址解析给用户。

方式二 基于网络就近性判断和广域三角重定向

与方式一相比，本全局负载均衡策略的不同点也是最大优点在于：AppDirector-Global不仅可以解析相应的域名，同时还根据用户真实IP 地址来进行最优站点计算和判断，最终将用户流量重定向相应的服务节点上。当用户请求的服务使用的协议不具有类似于"HTTP 302"的重定向命令时，该策略的顺利实现利用Radware AppDirector-Global产品所独具的"广域三角重定向"能力来完成服务的重定向。

方式三 基于http重定向

当用户请求的服务使用的是http的协议时，可以通过对用户真实的IP地址位置进行就近性计算，由AppDirector-Global发送"HTTP 302"的重定向命令，指引用户访问最佳站点。

方式四 基于rtsp重定向

当用户请求的服务使用的是rtsp的协议时，可以通过就近性计算，由AppDirector-Global发送"HTTP 302"的重定向命令，指引用户访问最佳站点。

2.2.2 就近性计算

为了能够准确计算出全球范围的用户在访问资源时，能够将用户导向"最优"的数据中心前，全局负载均衡器必需经过周密的运算，对用户到各站点之间的距离、延时、及当前数据中心的负载情况等因素全部考虑后，才能真正判断出当前"最优"的服务数据中心。

Radware的设备支持两种就近性计算的方法,建议采用两种方式并存使用。

方式一 静态就近性运算

该方式采用静态地址表的方式对用户的请求进行引导。当用户的IP地址或LDNS的IP地址命中静态地址表时，AppDirector-Global直接将用户导向已定义的最佳站点。当没有命中静态地址表时，则采用动态就近性运算方式。

方式二 动态就近性运算

Radware的动态就近性方式已申请专利，该方式可以根据用户真实位置或LDNS与各站点的往返延时、hops、及各站点的当前负载情况，进行组合运算(三个条件可以设置计算权值),将用户导向最佳站点。

为避免动态计算时为用户带来的访问延时，Radware设备对已查询过的IP地址采用C类地址的计算结果保存方式，对于在同一C类地址内的用户，直接调用已查计算过的地果。另外，可以手工设置计算结果的保留时间。

2.2.3 健康状况检查

AppDirector-Global可靠的健康状况检查可以保证用户获得最佳的服务站点。AppDirector-Global可以监视服务器在IP、TCP、UDP、应用和内容等所有协议层上的工作状态。如果发现故障，用户即被透明地重定向到正常工作的服务站点上。这可以保证用户始终能够获得他们所期望的信息。

为了确保服务正常运行，AppDirector-Global监控从 Web 服务器、中间件服务器到后端数据库服务器的整个路径上工作状态，确保整个数据路径上的服务器都处于正常状态。如果存在一个故障服务器，AppDirector-Global则不会将用户分配到这个发生故障路径的服务器，从而保证为用户提供透明的数据完整性保障。

2.2.4 交易完整性的可靠保证

AppDirector-Global基于DNS会话保持的特性，可以保证用户的相同会话请求始终保持在同一站点的服务器上。

为了保证用户在访问具有会话连续性业务时不会被负载均衡器分配到不同的服务器上，AppDirector-Global在提供本地负载均衡的同时，还可以具备基于cookie,session,source IP等方式将用户的请求定位在相同的服务器上。

2.2.5 完全的容错与冗余

AppDirector-Global的配置提供设备间的完全容错，以确保网络最大的可用性。两台AppDirector-Global设备工作在冗余模式下，通过网络相互检查各自的工作状态，为其所管理的应用保障完全的网络可用性。它们可工作于"主用-备用"模式或"主用-主用"模式，在"主用-主用"模式下，因为两个设备都处于工作状态，从而最大限度地保护了投资。并且所有的信息都可在设备间进行镜像，从而提供透明的冗余和完全的容错，确保在任何时候用户都可以获得从点击到内容的最佳服务。

2.2.6 通过正常退出服务保证稳定运行

当需要进行服务器升级或系统维护时，AppDirector保证稳定的服务器退出服务以避免服务中断。当选定某台服务器要从服务器退出服务后，AppDirector将不会将任何新的用户分配到该服务器。但是，它可以要退出服务的服务器上完成对当前用户的服务。从而保证了无中断的优质服务，以及服务器组的简易管理能力。

2.2.7 智能的服务器服务恢复

将重新启动的服务器应用到服务中时，避免新服务器因突然出现的流量冲击导致系统故障是非常重要的。所以，在将新服务器引入服务器组时，AppDirector将逐渐地增加分配到该服务器的流量，直至达到其完全的处理能力。从而不仅保证用户在服务器退出服务时，同时还保证服务器在启动期间以及应用程序开始时，均能获得不间断服务。

2.2.8 通过负载均衡优化服务器资源

AppDirector执行复杂的负载均衡算法，在多个本地和远程服务器间动态分配负载。这些算法包括循环、最少用户数、最小流量、Native Windows NT 以及定制代理支持。除了这些算法，AppDirector还可以为每个服务器分配一个可以配置的性能加权，从而提高服务器组的性能。

2.2.9 应用交换

AppDirector根据 IP 地址、应用类型和内容类决定流量分配。这样，管理员就可以为不同类型的应用程序分配不同的服务器资源。应用交换支持不同协议上的各种应用，包括 TCP、UDP、IP、Telnet、Rshell、TFTP、流、被动 FTP、HTTP、e-mail、DNS、VOIP 等等。Radware 还为运行于动态端口并要求同步的应用设计了特殊支持功能。

2.2.10 URL交换

AppDirector完全支持 URL 交换，根据 URL 和 HTTP 信息分配流量。每个 URL 都可以重定向到某服务器，或在多个服务器之间进行负载均衡，从而提供优化的 Web 交换性能。根据 URL 文本中包含的信息，AppDirector可以保持客户持续性，从而保证内容的个性化。

2.2.11 内容交换

内容交换使管理员可以根据交易的内容来分配服务器资源。例如，CGI 脚本可以位于一个单独的服务器组，当发生对该内容的请求时，会话就被重定向到其中某个服务器。AppDirecto-Global的内容交换能力可以广泛支持 SSL ID 和 Session ID， 保持客户持续性，保证最佳流量管理和应用内容个性化。

2.3 AppDirecto-Global实现带宽管理

带宽管理软件模块是一个简单的概念主要的思想就是能够按照一系列标准区分用户流量，然后为每种数据包或者会话指定不同的优先级来使用有限的带宽。它允许网络管理者完全而有效的控制他们可用的带宽，使用这些功能可以按照一系列标准，指定应用程序的优先次序，同时还考虑了每个应用程序已使用的带宽。在确定了会话的优先级后可以对带宽限制进行配置以保证一些应用程序使用的带宽没有超过预先定义的带宽限制。

2.4 AppDirecto-Global实现端到端应用安全解决方案

应用安全软件模块包含的一组功能集使Radware 的产品能够保护敏感的网络资源不受到各种安全问题的影响。此系统包括一些基本的安全措施例如服务器过载保护和能够将资源从一般的Internet 资源中隐藏起来。同时还能够为使用SynApps 流量管理的敏感资源提供高级的安全性，这包括检测并预防1500多个恶意攻击信息，包括特洛伊木马、后门、DoS 和DdoS 攻击。

此模块能够处理以下攻击：

  • 拒绝服务 (DOS/DDOS) 攻击
  • 缓冲区溢出/超限
  • 利用已知的 Bugs，误配置和默认的安装问题来进行攻击
  • 在攻击前探测流量
  • 未授权的网络流量
  • 后门/特洛伊木马
  • 端口扫描 (Connect & Stealth)

3. Radware 全局解决方案的优势

3.1.1 AppDirector-Global同时支持本地和全局服务器负载均衡

Radware 的AppDirector-Global既可以进行本地的服务器负载均衡，也可以同时进行全局服务器的负载均衡，这样，对于一个系统来说，在刚开始只需要本地服务器负载均衡的时候，可以购买Radware的AppDirector来进行本地的服务器负载均衡，AppDirector相对AppDirector-Global来说比较便宜，可以节省用户的投资，随着业务量的不断增加，如果用户需要进行全局的服务器负载均衡，可以非常方便的把现有的AppDirector通过license升级为AppDirector-Global可以充分利用原有的投资，避免不必要的浪费。

3.1.2 Radware的全局三角传输技术可以确保真正的网络就近性判断

Radware在全局重定向解决方案上可以支持HTTP重定向，DNS重定向，全局三角传输重定向（Radware 专利技术）。其专利技术的三角传输全局重定向技术可以解决HTTP,DNS重定向的某些局限性。而其他厂商目前只支持HTTP，DNS重定向技术，所以在特定的HTTP和DNS重定向无法满足用户需求的情况下只有Radware的解决方案可以满足用户的需求。

HTTP重定向的问题：

HTTP重定向技术使用了HTTP协议自带的重定向机制，所以不需要用户做相应的改动，但是由于HTTP重定向技术制支持HTTP协议的重定向，如果用户除了HTTP业务还有其他的应用需要作全局的重定向，HTTP重定向技术就无法满足用户的需求了。

DNS重定向的问题：

DNS重定向技术由于是发生在用户DNS解析阶段，所以DNS重定向技术可以支持所有通过DNS解析的应用的全局重定向，但是由于DNS重定向在做就进性检测的时候检测的是用户设置的DNS服务器的地址，而不是用户的真实IP，所有就近性的检查不是针对用户的IP的，这样在一个城域网的环境中，DNS服务器只有一个，这样用户的访问会集中到离DNS服务器近的站点，没有做到真正的用户就近重定向。

由于HTTP重定向以及DNS重定向技术存在的问题，所以在某些情况下，HTTP重定向技术和DNS重定向技术无法满足用户的需求，比如一个运营商在一个城域网内部署流媒体服务，HTTP重定向无法进行流媒体业务的重定向，而DNS重定向的就近性检查是针对用户的DNS服务器进行的，在城域网中，由于一个运营商的DNS服务器只有一个，这样，如果通过DNS重定向的方式，会造成用户的就近性检查不准，从而使得靠近DNS服务器的服务点的用户数量大，而其他服务点的用户数量少，所以DNS重定向的方式也无法满足用户的需求。

Radware的全局三角传输技术可以很好的解决上述2个问题:

  • 支持流媒体业务的全局重定向
  • 准确的就近性判断

Radware的全局重定向技术可以对各种应用进行全局重定向，另外Radware的全局重定向在就近性检测是对用户的真实ＩＰ进行的就近性的检查，就近性的检测是真实的

3.1.3 Radware的全局重定向技术可以支持三级的重定向

Radware的全局重定向技术，可以通过各种重定向方法的混合使用，实现三级的全局服务器重定向，目前只有Radware的解决方案可以实现该功能。

通过三级重定向技术，使得站点的无限扩充成为可能。

posted @ 2008-01-28 23:21 加菲猫 阅读(185) | 评论 (0) | 编辑
CDN的历史和厂商

•1996 美国MIT的一个研究小组提出CDN 概念

•1999年全球第一个专业CDN服务网络投入商用

•第一个正式用户－Yahoo

 

国际上主要CDN服务提供商

•AKAMAI

•Digital Island (C&W)

•Ibeam(卫星CDN服务）

•Speedera

•Cidera

•Real（流媒体服务）

•AT&T

•….

 

国际上主要CDN设备提供商

•CISCO

•NORTEL

•F5

•BlueCoat (CacheFlow)

•Inktomi

•Netapp （以缓存设备起家，06年NetCache产品卖给BlueCoat了，从此专心做存储)

•Foundry Networks

•Array Networks

•….

 

CDN在中国

•Akamai、Digital Island等开始在国内建点

•国内一些IDC、ISP开始代理销售国外CDN服务商的服务

•电信运营商建立自己内部的或区域的CDN网络 - 大量使用NetApp/Radware的硬件产品。VOD CDN上华为思华创智有一定份额

•独立的CDN服务提供商——ChinaCache

  1. 2000年初在信息产业部的支持下ChinaCache 开始商业试验
  2. Sina成为第一个使用ChinaCache CDN服务的客户
  3. 2002年6月正式批准商业运营
  4. 截至2007年9月ChinaCache在全国80多个大中城市拥有近350个节点，全网处理能力突破400Gbps

 

关于ChinaCache的使用的设备和技术(仅从公开信息收集,不一定准确)

最开始使用Array NetWorks的产品

后来使用F5的产品(应该是3DNS-GSLB)

使用Squid作为web cache

使用NetCache作为流媒体Cache

posted @ 2008-01-28 23:20 加菲猫 阅读(125) | 评论 (3) | 编辑
NetApp 把 NetCache 业务出售给 Blue Coat Systems

今天在NetApp的网站上找NetCache的资料，结果发现在06年就已经卖掉了

http://www-cn.netapp.com/products/netcache/bluecoat.html

NetApp 把 NetCache 业务出售给 Blue Coat Systems

2006 年 9 月 11 日，Network ApplianceTM 完全将其 NetCache 业务资产出售给 Blue Coat Systems Inc。有关 Web 代理缓存解决方案的详细信息，请联系 Blue Coat Systems。如果您当前是 NetApp 的客户，并且想要了解有关 NetCache 产品问题的信息，请通过我们的 NOW (NetApp On the Web) 网站联系 NetApp 全球服务。

posted @ 2008-01-28 23:20 加菲猫 阅读(39) | 评论 (0) | 编辑
Radware WSD的服务器健康检查

参考： WSD的服务器管理 / 先进的健康检查模块

WSD通过下面的方法来检查服务器状态：

1. Ping

2. 连接TCP端口

3. 检查UDP端口的响应

4. HTTP专用选项

  • -定期检查每个服务器上页面、文件的存在
  • -检查http response code， 一般是检查是否200，用户可以配置"可接受"的返回代码
  • -假如返回200的话，检查页面里面是否有配置的的字符串存在

 

WSD在创建服务器群集的时候，需要配置下面的参数：

1. 检查连接性方法，如上面所示

2. 检查连接性端口

3. 轮询间隔

4. 重试次数

5. 主页：检查http页面的

6. 检索频率：和主页一起使用

还有一些设置，是检查HTTP内容使用的

posted @ 2008-01-27 17:13 加菲猫 阅读(64) | 评论 (0) | 编辑
GSLB - Selecting the Best Site

先得说一个重要问题：假如采用DNS-GSLB，向GSLB服务器发出查询的是LocalDNS而不是end user, GSLB得不到end user的ip地址，也无法保证local DNS有和end user相近的响应时间。

Site Health Conditions

GSLB需要检查每个SITE的健康情况，GSLB只能把用户导向能够正常服务的SITE. 假如每个SITE有一个load balancer, 那么GSLB就向SLB的VIP发送健康检查请求。SLB把健康检查请求当作一个正常请求并将它forward到real server。健康检查的方式很多，就好象做server的健康检查一样：layer 2/ 3/ 4/ 7 都可以做检查，GSLB可以发送HTTP请求检查返回代码，检查返回内容中的关键词或者校验和。

image

Site Response Time

GSLB可以测量每个site的请求/回应往返时间，就使用健康检查的往返时间就可以了。但是要知道，GSLB到服务器的往返时间和end user的体验并没有直接关系，往返时间可以分为3部分，客户端延时+服务器响应时间+网络延迟。GSLB测量得到的数据无法体现user-server网络延迟。

GSLB可以测量的响应时间本质上反映了一个site的服务器响应时间，假如一个SITE有SLB和多个real server，那么几次请求会被导向到不同的real server，结果会有不同，所以最好测量多次相应的平均时间。Local Server load balancer 可以测量所有服务器的加权平均响应时间报告给GSLB。

Site Load Conditions

我们必须同时考虑site的服务能力和服务负载。GSLB将user导向最优服务能力的site是有必要的。但是如何定义服务器负载是一个有争议的话题。当前的并发连接是一个可用的指标，服务器响应时间也反映了服务器负载。没有一个特定的方法来定义服务器负载。

通过DNS，即使采用某种方法选择负载最轻的服务器后，你无法预知会影响多少个新的请求，因为LocalDNS有cache，也许接下来只有一个请求，或者是上万次的请求都会定向到那台服务器。

Geography−Based Site Selection

ip地址被分为很多块对应于国家和大陆，GSLB将LocalDNS的地址匹配地址块，选择相近的服务器服务。这个方法只能近似的选择合适的服务器，不过误差是可以容忍的。

因为服务器负载或者临时性的网络拥塞，一个用户选择相近的服务器未必能够得到最好的体验。

User Response Time−Based Site Selection

end−user response time = client−side delay + Internet　delay + and server−side delay

服务端delay是独立于用户的位置并且是GSLB可以测量的，客户端delay我们啥也不能做，网络延时取决于客户端和服务器的位置。我们知道服务器的位置，但是无法确知用户的位置，他们可能遍布世界各地。测量网络延时有几种方法，但是没有一个是完美的。

Ping

GSLB解析DNS请求的时候，让每个SLB去ping LocalDNS，报告ping 时间给GSLB，GSLB选择最短的ping时间服务器。这种方式下，GSLB必须等待各个SLB的ping结果报告，有明显的性能问题。解决的方法是GSLB先使用其他策略，在后台收集SLB ping local dns的数据，供下次请求使用。这样就不会影响性能，但是影响第一次dns请求的解析结果。

另外, ping结果本身并非很准确，需要测量多次取平均值，而且容易被防火墙挡住。

DNS Reply Race

GSLB转发dns 请求给SLB，SLB发送自己的VIP给local DNS, Local DNS采用第一个收到的dns reply。这里有个关键问题是如何让SLB在同一个时间点发送dns reply，无论如何调整，这个也只能做到近似，而且，这样找到最少网络延时也只是一个瞬间状态而不是有代表性的平均值。

TCP Response Time

GSLB先使用其他策略，local SLB测量client发送的SYN和ACK之间的时间差，就可以知道网络延时，这种测量不需要额外的流量，非常有效率，而且即使local dns在防火墙后面也无所谓。

SLB要将测量的结果报告GSLB。GSLB为了比较不同的SLB-用户网络延时，需要将同样的用户导向各个SLB。

一个问题：SLB测量的是end-user的网络延时，但是GSLB只知道LocalDNS的地址，将用户的ip地址和local DNS地址关联是个较大的挑战。

定义group的方法不多说，现在其实我们做出了两个假设：同一个group的ip地址有相同的时延，而且使用相同的local DNS。

一个重要的概念是如何将internet地址分组，像Border Gateway Protocol (BGP)这样的路由协议可以帮助我们。

因为要不断的收集数据，总有些用户会被分到延时较远的site，这无疑会影响他们的体验。一种替代的方法是在网络上广泛使用机器人来测量延时，但是部署是个大问题。

Routing Cost

用户到SLB经过多少跳可以作为网络延时的一个指标。假如GSLB使用BGP协议，他就可以得到地址段到SLB之间的跳数信息。

但是跳数不一定能够准确的反映网络延时信息，因为拥塞等原因

 

Affinity

Tolerance Values

Selecting the Best Site

当收到请求的时候，GSLB必须确保只有功能正常的site选中，然后再通过其他方式缩小可选范围，我们可以使用加权的各种尺度来衡量最佳的site。

当选择出最佳的站点后，GSLB可以只回应一个ip地址或者是一个地址列表，假如回应地址列表，localDNS一般会采用轮转的方法来回应请求。假如只返回一个ip地址，当别选择服务器宕机后，我们只能等待local dns  or client cache time-out。

posted @ 2008-01-27 01:08 加菲猫 阅读(144) | 评论 (4) | 编辑
居然就这么没有了

一直用live writer。决定把一篇文章分成两个部分发，剪切了一段出去，新建了一个帖子粘帖，再切换一个草稿，居然发现找不回刚才新建的帖子了！！！ 那么多内容白写了！

posted @ 2008-01-27 00:48 加菲猫 阅读(19) | 评论 (0) | 编辑
内容交换

内容交换是一种智能交换技术，通过对内容进行深入检查作出相应的流量重定向决策.

posted @ 2008-01-26 23:55 加菲猫 阅读(16) | 评论 (0) | 编辑
gvim for windows的剪贴板操作

因为windows用久了，觉得还是edit-plus或者ultra-edit大部分情况比unix下面的vi好用。但是说句实话，在检查log文件的时候，这些工具就拍马也比不上vi了，怀疑是否这也是vi设计的初衷之一？

因为懒得把log文件拷贝到unix/linux下面再使用vi，所以就下载了gvim的windows版本 :)

image

其实看log不过是复制粘贴，search而已。 不过在windows gvim下面，熟悉的ctrl+C/V 却不能用，找了一下，用下面的命令就可以方便的操作剪贴板了, 其实这些本来就是windows下面ctrl+C/V的替代快捷方式:

Shift-Insert 粘贴文本（从剪贴板） *<S-Insert>*

CTRL-Insert 复制选择的文本（到剪贴板） *<C-Insert>*

CTRL-Del 剪切选择的文本（到剪贴板） *<C-Del>*

Shift-Del 剪切选择的文本（到剪贴板） *<S-Del>*

posted @ 2008-01-25 22:19 加菲猫 阅读(141) | 评论 (0) | 编辑
智能DNS - 笔记

参考资料: Load Balancing Servers, Firewalls, and Caches / WSD产品文档

要点：

  • local dns (local name server)是客户端网络设置的一部分，要么是手工配置，要么从DHCP得到。一般local dns 在从网络上靠近客户端。
  • 主要的域，比如.com .net .org 等，都由Internet管理方进行管理维护，负责这些域的服务器也叫"根服务器", 根服务器里面有 foo.com 之类的子域，每个子域有一个或者多个服务器，这就是子域的权威服务器（授权DNS服务器）。
  • 授权DNS服务器存储对于管理一个域名的重要信息，同时一个域名可以分为多个Zone，个Zone可以有各自的授权DNS,称为Zone of Authority(ZOA). 比如a.foo.com b.foo.com 可以有各自的ZOA
  • 可以有一个或者多个授权DNS服务器，但是只有一个 primary authoritative DNS 负责分发域名name space的信息。

迭代查询和递归查询：

迭代查询：服务器可以回答确切答案，或者告知查询者其他可能知道答案的服务器。

递归查询：服务器必须回答确切答案，假如自己不知道，就要通过查询其他服务器得到答案。

客户端的DNS解析器一般无法处理迭代的回答，所以查询localDNS一般使用递归方式。服务器DNS解析器可以回答迭代或者递归查询，也可以发出递归或者迭代查询。

 

典型DNS查询流程:

image

1. 客户端向local dns查询 www.foo.com，注意这是递归查询

2.3. local dns 向 root name servers  查询 .com 的name server. 这里采用迭代方式。

4.5. local dns 向 .com 的 name server 查询 foo.com 的授权dns

6.7. local dns 向 foo.com 的授权dns得到 www.foo.com 的ip list

8.    local dns 将 www.foo.com 的一个ip返回给客户端

9.    客户端访问 ip 指向的服务器

 

Local DNS Caching

DNS 信息有一个TTL消息， local dns 可以cache dns reply ，过期时间就是这个ttl时间。

假如dns cache信息过期，local dns 向授权dns服务器重新请求。

假如local dns 收到的dns查询响应有多个ip 地址，对于客户端的查询，将采用round-robin策略

客户端也可以cache dns 响应，但是部分客户端忽略ttl信息而采用自己的固定dns过期时间，比如微软的IE

 

Using Standard DNS for load balancing

DNS可以做load banlancing服务，对于一个域名可以配置多个ip地址，这些ip指向load balancer的VIP或者只是一台真实服务器。但是DNS无法知道某个ip是否能否服务或者负载情况如何(这个不是绝对的，参看下面GLSB部分)，毕竟 DNS 并不是为 GLSB 设计的。

DNS−Based GSLB

需要load balancer在DNS framework框架内，为特定客户端选择最合适的server的ip地址。这里分为两个问题：

  1. balancer如何纳入dns框架内, 返回最合适的ip地址给客户端？
  2. load balancer如何知道谁是最好的site？

将load balancer嵌入 GLSB 有几种途径：

The Load Balancer as the Authoritative DNS

最简单的方法是load balancer作为域名或者Zone的授权DNS, 作为授权DNS服务器，load balancer可以智能的响应DNS查询，大部分GLSB产品可以实现这种该功能.

image

不同的GSLB产品的不同实现是一个需要考虑的问题. F5 3DNS有完整的DNS实现, 而 Foundry, Nortel, Cisco, Radware 的产品实现了不同的DNS功能，假如某个产品不能处理特定的查询，它就会丢弃查询，返回错误或者转寄查询到一个真实的DNS server。对于客户，这意味着他们得放弃原来使用的一些DNS功能。

The Load Balancer as Forward DNS Proxy

forward proxy server 明确的代表另一台服务器。load balancer 注册为域名的授权DNS，作为真正的授权DNS服务器的代理。对于DNS查询，load balancer 转寄给授权DNS，修改其回应来实现GLSB功能。只对于特定GLSB域名的name-address 解析命令，load balancer才会需要dns响应

image

这种方案有很多好处：

可以使用多个DNS server ，来得到高可用性和高扩展性

DNS server可以在私有网络内，来增强安全性

可以透明的增加和移走DNS server

Load balancer不需要实现所有的DNS功能，进一步地说，GSLB功能可以很好的和普通的load balancing功能共存。

image 

Load balancer有两个VIP: VIPD是作为授权DNS proxy的地址，VIP1是server farm (new york)的地址。当然，这两个VIP可以使用同一个地址。

有了forward dns proxy, 我们可以把真实的授权dns服务器放在任何地方。一般是客户控制授权DNS，而服务提供商使用forward dns proxy 来提供GLSB服务。load balancer 的VIP要被注册为授权DNS服务地址。假如真实授权dns比较远，到它的查询有明显的时延，这时候为了性能，load balancer就要像local dns一样缓存dns查询。

假如有人需要不修改任何dns设置怎么办？forward dns proxy 可以把原来的授权dns换一个ip，原来的IP给load balancer，或者是设置授权DNS地址，指向新的load balancer的VIP。总之还是要修改原有授权dns的一些设置。

透明DNS proxy可以避免修改任何DNS设置。

Limitations of DNS−Based GSLB

毕竟DNS并不是为GSLB设计的。

1. LocalDNS和用户可能网络距离很远，我们无法保证这一点，特别是使用固定的DNS设置的用户。不过现在使用DHCP的用户越来越多了，一般而言local DNS和用户拥有相似的网络延时

2. 某些Local DNS和browser忽略授权DNS的TTL设置，使用固定的dns超时时间。有些browser假如不关闭重启，就不会更新dns cache

posted @ 2007-12-30 20:54 加菲猫 阅读(94) | 评论 (0) | 编辑