固定IP有什么用？

地址租期的意思是，当一个Ip分配给MAC地址后，在租期内，默认这个MAC地址的IP为改地址，不再进行分配。

当到期后，该地址被回收，重新分配。

设置地址租期，对于减轻DHCP压力，网络稳定有一定的好处，但是有些时候网络会因此出现诸如IP地址不够等一些问题。

所以租期的时间需要你依据你单位实际情况合理分配！

DHCP安装

1 依次点击“开始→设置→控制面板→添加/删除程序→添加/删除Windows组件”，打开相应的对话框。

2 用鼠标左键点击选中对话框的“组件”列表框中的“网络服务”一项，单击[详细信息]按钮，出现带有具体内容的对话框。

3 在对话框“网络服务的子组件”列表框中勾选“动态主机配置协议（DHCP）”，单击[确定]按钮，根据屏幕提示放入Windows 2000安装光盘，复制所需要的程序。

4 重新启动计算机后，在“开始→程序→管理工具”下就会出现“DHCP”一项，说明DHCP服务安装成功。

GFS的新颖之处并不在于它采用了多么令人惊讶的新技术，而在于它采用廉价的商用计算机集群构建分布式文件系统，在降低成本的同时经受了实际应用的考验。
如上图所示，一个GFS包括一个主服务器（master）和多个块服务器（chunk server），这样一个GFS能够同时为多个客户端应用程序（Application）提供文件服务。文件被划分为固定的块，由主服务器安排存放到块服务器的本地硬盘上。主服务器会记录存放位置等数据，并负责维护和管理文件系统，包括块的租用、垃圾块的回收以及块在不同块服务器之间的迁移。此外，主服务器还周期性地与每个块服务器通过消息交互，以监视运行状态或下达命令。应用程序通过与主服务器和块服务器的交互来实现对应用数据的读写，应用与主服务器之间的交互仅限于元数据，也就是一些控制数据，其他的数据 *** 作都是直接与块服务器交互的。这种控制与业务相分离的架构，在互联网产品方案上较为广泛，也较为成功。
⑷单master
只 有一个master也极大的简化了设计并使得master可以根据全局情况作出精密的块放置和复制决定。但是我们必须要将master对读和写的参与减至 最少，这样它才不会成为系统的瓶颈。Client从来不会从master读和写文件数据。Client只是询问master它应该和哪个 chunkserver联系。Client在一段限定的时间内将这些信息缓存，在后续的 *** 作中Client直接和chunkserver交互。
以图1解释一下一个简单的读 *** 作的交互。
⒈client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引（chunk index）。
⒉给master发送一个包含文件名和块索引的请求。
⒊master回应对应的chunk handle和副本的位置（多个副本）。
⒋client以文件名和块索引为键缓存这些信息。（handle和副本的位置）。
⒌Client 向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了chunk handle（chunkserver以chunk handle标识chunk）和块内的一个字节区间。
⒍除非缓存的信息不再有效（cache for a limited time）或文件被重新打开，否则以后对同一个块的读 *** 作不再需要client和master间的交互。
通常Client可以在一个请求中询问多个chunk的地址，而master也可以很快回应这些请求。
⑸块规模
块规模是设计中的一个关键参数。我们选择的是64MB，这比一般的文件系统的块规模要大的多。每个块的副本作为一个普通的Linux文件存储，在需要的时候可以扩展。
块规模较大的好处有：
⒈减少client和master之间的交互。因为读写同一个块只是要在开始时向master请求块位置信息。对于读写大型文件这种减少尤为重要。即使对于访问少量数据的随机读 *** 作也可以很方便的为一个规模达几个TB的工作集缓缓存块位置信息。
⒉Client在一个给定的块上很可能执行多个 *** 作，和一个chunkserver保持较长时间的TCP连接可以减少网络负载。
⒊这减少了master上保存的元数据（metadata）的规模，从而使得可以将metadata放在内存中。这又会带来一些别的好处。
不利的一面：
一个小文件可能只包含一个块，如果很多Client访问该文件的话，存储这些块的chunkserver将成为访问的热点。但在实际应用中，应用程序通常顺序地读包含多个块的文件，所以这不是一个主要问题。
⑹元数据（metadata）
master 存储了三种类型的metadata：文件的名字空间和块的名字空间，从文件到块的映射，块的副本的位置。所有的metadata都放在内存中。前两种类型 的metadata通过向 *** 作日志登记修改而保持不变， *** 作日志存储在master的本地磁盘并在几个远程机器上留有副本。使用日志使得我们可以很简单 地、可靠地更新master的状态，即使在master崩溃的情况下也不会有不一致的问题。相反，master在每次启动以及当有 chunkserver加入的时候询问每个chunkserver的所拥有的块的情况。
A、内存数据结构：
因为metadata存储在内存中，所以master的 *** 作很快。进一步，master可以轻易而且高效地定期在后台扫描它的整个状态。这种定期地扫描被用于实现块垃圾收集、chunkserver出现故障时的副本复制、为平衡负载和磁盘空间而进行的块迁移。
这 种方法的一个潜在的问题就是块的数量也即整个系统的容量是否受限与master的内存。实际上，这并不是一个严重的问题。Master为每个 64MB的块维护的metadata不足64个字节。除了最后一块，文件所有的块都是满的。类似的，每个文件的名字空间数据也不足64个字节，因为文件名 是以一种事先确定的压缩方式存储的如果要支持更大的文件系统，那么增加一些内存的方法对于我们将元数据（metadata）保存在内存中所获得的简单 性、可靠性、高性能和灵活性来说，这只是一个很小的代价。
B、块位置：
master并不为chunkserver所拥有的块的副本的保存一个不变的记录。它在启动时通过简单的查询来获得这些信息。Master可以保持这些信息的更新，因为它控制所有块的放置并通过HeartBeat消息来监控chunkserver的状态。
这样做的好处：因为chunkserver可能加入或离开集群、改变路径名、崩溃、重启等，一个集群中有成百个server，这些事件经常发生，这种方法就排除了master与chunkserver之间的同步问题。
另一个原因是：只有chunkserver才能确定它自己到底有哪些块，由于错误，chunkserver中的一些块可能会很自然的消失，这样在master中就没有必要为此保存一个不变的记录。
C、 *** 作日志：
*** 作日志包含了对metadata所作的修改的历史记录。它作为逻辑时间线定义了并发 *** 作的执行顺序。文件、块以及它们的版本号都由它们被创建时的逻辑时间而唯一地、永久地被标识。
*** 作日志是如此的重要，我们必须要将它可靠地保存起来，并且只有在metadata的改变固定下来之后才将变化呈现给用户。所以我们将 *** 作日志复制到数个远程的机器上，并且只有在将相应的日志记录写到本地和远程的磁盘上之后才回答用户的请求。
Master可以用 *** 作日志来恢复它的文件系统的状态。为了将启动时间减至最小，日志就必须要比较小。每当日志的长度增长到超过一定的规模后，master就要检查它的状态，它可以从本地磁盘装入最近的检查点来恢复状态。
创 建一个检查点比较费时，master的内部状态是以一种在创建一个检查点时并不耽误即将到来的修改 *** 作的方式来组织的。Master切换到一个新的日志文件并在一个单独的线程中创建检查点。这个新的检查点记录了切换前所有的修改。在一个有数十万文件的集群中用一分钟左右就能完成。创建完后，将它写入本地和 远程的磁盘。
⑺数据完整性
名字空间的修改必须是原子性的，它们只能有master处理：名字空间锁保证了 *** 作的原子性和正确性，而master的 *** 作日志在全局范围内定义了这些 *** 作的顺序。
文件区间的状态在修改之后依赖于修改的类型，不论 *** 作成功还是失败，也不论是不是并发 *** 作。如果不论从哪个副本上读，所有的客户都看到同样的数据，那么文件 的这个区域就是一致的。如果文件的区域是一致的并且用户可以看到修改 *** 作所写的数据，那么它就是已定义的。如果修改是在没有并发写 *** 作的影响下完成的，那么受影响的区域是已定义的，所有的client都能看到写的内容。成功的并发写 *** 作是未定义但却是一致的。失败的修改将使区间处于不一致的状态。
Write *** 作在应用程序指定的偏移处写入数据，而record append *** 作使得数据（记录）即使在有并发修改 *** 作的情况下也至少原子性的被加到GFS指定的偏移处，偏移地址被返回给用户。
在一系列成功的修改 *** 作后，最后的修改 *** 作保证文件区域是已定义的。GFS通过对所有的副本执行同样顺序的修改 *** 作并且使用块版本号检测过时的副本（由于chunkserver退出而导致丢失修改）来做到这一点。
因为用户缓存了会位置信息，所以在更新缓存之前有可能从一个过时的副本中读取数据。但这有缓存的截止时间和文件的重新打开而受到限制。
在修改 *** 作成功后，部件故障仍可以是数据受到破坏。GFS通过master和chunkserver间定期的handshake，借助校验和来检测对数据的破坏。一旦检测到，就从一个有效的副本尽快重新存储。只有在GFS检测前，所有的副本都失效，这个块才会丢失。