<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>思维 &#187; 服务器</title>
	<atom:link href="http://blog.acmind.com/archives/tag/%e6%9c%8d%e5%8a%a1%e5%99%a8/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.acmind.com</link>
	<description>Acme of Mind</description>
	<lastBuildDate>Mon, 19 Apr 2010 02:23:51 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>服务器虚拟化介绍</title>
		<link>http://blog.acmind.com/archives/902</link>
		<comments>http://blog.acmind.com/archives/902#comments</comments>
		<pubDate>Tue, 02 Jun 2009 08:01:06 +0000</pubDate>
		<dc:creator>笑谈</dc:creator>
				<category><![CDATA[学习应用]]></category>
		<category><![CDATA[虚拟化]]></category>
		<category><![CDATA[服务器]]></category>

		<guid isPermaLink="false">http://blog.acmind.com/?p=902</guid>
		<description><![CDATA[什么是虚拟化，为什么要虚拟化？
虚拟化是在单个物理服务器上运行多个独立的虚拟操作系统的一种方法。是通过最大化物理资源来达到投资最大化的一种途径。既然摩尔定律已经准确地预测出计算能力的指数增长，而对于同样的计算任务而言，硬件需求大部分没有改变,那么现在，把一台极其廉价的双槽双核1U机架式服务器，拆分为8个乃至16个虚拟服务器就已经变得可行了。虚拟化技术是获得更高服务器密度的一种方式。不过，实际上它并没有提升总体的计算能力；其实由于额外开销，计算能力还略有下降。但是，由于一台现代的3000美元2插槽4核服务器，比4年前30000美元的8插槽8核服务器还要强大，我们就可以通过在这种新硬件上增加逻辑操作系统的数量来开发它的能力。这可以削减主要的硬件购置和维护费用，从而最终显著地节省公司或组织的成本。
什么时候该虚拟化？
虚拟化是中小规模应用的完美解决方案。虚拟化不应该用在那些需要1到多台服务器进行集群方能满足需求的高性能应用上，因为增加的开销和复杂性只会降低性能。基本上我们是在拿一个12GHz（3GHz的四核CPU）的服务器来把它拆解为 16个750MHz的服务器。不过一旦有8个那样的服务器处于非忙时或空闲时，其余的8个服务器将能得到约1.5GHz的主频。
尽管在虚拟化行业里面有人喜欢宣扬高CPU利用率作为硬件优化使用的指标，这种建议不应该走极端，在应用的响应性超限了还使用。一个简单的经验法则是，永远也不要让服务器的CPU利用率在峰值负荷的情况下超过50%；更为重要的是，永远不要让应用的响应时间超过合理的SLA （服务水平协议） 。 大部分内部使用的先进服务器的任务是把CPU利用率控制在1-5%之间 。在单台物理服务器上运行8个操作系统会把峰值CPU利用率提高到将近50% ，但平均水平要低得多，因为虚拟操作系统的波峰波谷,或多或少地,会趋于相互抵消。
尽管在今天现有大部分的虚拟化解决方案里，出现CPU过载的很少，但存储及网络吞吐量的I/O（输入/输出）过载则是另一回事。对于有着高到极端的存储或硬件I/O需求的服务器来说，运行于裸机之上会更为明智一些，即便其CPU需求可在虚拟环境中得到满足。
如何避免“所有鸡蛋都放在一个篮子上”综合症
虚拟化最大的忧虑是出现“所有鸡蛋放进同一篮子”综合症。把所有关键服务器都放进一台物理服务器是不是明智之举？当然不是！避免这种倾向的最简易的办法是确保单个服务没有驻留在单台服务器上。我们以下列服务器类型为例说明：

HTTP 
FTP 
DNS 
DHCP 
RADIUS 
LDAP 
使用光纤通道（FC）或iSCSI存储的文件服务storage 
Active Directory服务 

我们可以将这些类型的服务器中的每一个放置到至少2台物理服务器上，以便获得冗余性。这种类型的服务，由于在单台服务器失效的时候可方便地切换，相对而言比较易于集群。当单台物理服务器失败或需要进行服务的时候，在其他物理服务器上的另外的虚拟服务器会自动接替。通过横跨多台物理服务器，这些关键服务永远也不会因为单个硬件失败而停止运行。
对于像Exchange Server，Microsoft SQL ,MySQL或Oracle这样更为复杂的服务，集群技术可应用于在两台物理服务器上的两个逻辑服务器的同步；这种方法在转换的时候一般会导致约5分钟的停机时间。但这并非由于虚拟化，而是因为集群的复杂性往往需要时间去进行转换。处理这些复杂服务的一种替代办法,是把虚拟服务器从主物理服务器迁移至另一台物理服务器。为了让这个方法行之有效，需要不断地将内存从一台物理服务器同步到另一台，以便故障切换时间能在毫秒级的时间内完成，这样所有服务都能维持正常运行。
物理服务器向虚拟服务器的迁移
任何一个像样的虚拟化解决方案都会提供某种类型的P2V（物理到虚拟）迁移工具。该P2V工具会对一台已有的物理服务器的驱动器堆栈做一些必要的修改，来进行硬盘镜像的虚拟化，以便服务器可以虚拟服务器的形式进行启动和运行。这么做的好处是不必重建服务器，再人工把它们配置为虚拟服务器 — 只需原封不动地把服务器接收过来就行！
因此，如果你的数据中心充斥着主频低于GHz的日渐老化的服务器的话，它们正是P2V迁移的绝佳候选者。由于这些授权你已支付，你甚至无需为获取授权的成本担忧。你几乎可以腾出128台主频不过GHz的传统服务器的空间，让位于8台1U高的双槽四核服务器，服务器带双千兆以太网卡以及两套独立的iSCSI磁盘阵列，均通过千兆以太网交换机互联到一起。每年在老系统上花费的的硬件维护费足够支付购买这里所有的新硬件！尽管想象一下吧，进行这样的迁移之后，你的服务器空间会有多整洁。新硬件可全部装进一个机架中，给你腾出了大量的扩展空间。
作为虚拟化的一个额外的好处，你可以得到一个灾难恢复计划，因为虚拟化后的镜像可悲用于实时恢复所有服务器。自问一下，如果是传统的服务器的死掉的话会发生什么事情。你还记不记得如何从潦草的记录中去重建并重新配置回所有的服务器？（我想你现在就要哭出来了。）利用虚拟化，通过P2V镜像重建虚拟服务器，你可以在1个小时之内恢复Active Directory和Exchange Server。
虚拟服务器的补丁管理
虚拟服务器的补丁管理与正常服务器的并没有什么不同，因为每个虚拟操作系统就是自己独立的虚拟硬盘。你仍需要一个补丁管理系统来对所有服务器进行打补丁,不过未来可能会出现有趣的发展，如果服务器共享某些公共的操作系统或应用二进制代码的话，也许可以对多个操作系统同时打补丁。理想情况下，你可以为独立的或一组类似的服务器分配一种补丁级别。目前，还还需要像在其他操作系统上做过那样对虚拟操作系统进行打补丁，不过在虚拟化领域将有所创新，而你在物理服务器上是做不到这些的。
授权与支持方面的考虑
软件的许可是虚拟化的一大担忧。 谁都不想为运行于单台服务器上的16个虚拟会话支付16份许可。（高昂的）软件许可通常会令硬件开销相形见绌，因此在共享的硬件上运行一份许可为2万美元的软件是愚蠢的。这种情况下，最好是在速度最快的物理服务器上跑软件，不要进行任何虚拟化，以便增加开销。
对于像Windows Server 2003标准版这类的软件，需要为运行在物理服务器上的每个虚拟会话支付费用。此规则的例外是企业版，允许运行在1台物理机器上以1份许可分费用运行Windows Server 2003的4分虚拟拷贝。微软的这项许可策略应用于以Windows Server 2003为操作系统的任何虚拟技术上。
如果你用的是开源软件，就不必担心许可问题，因为它一直就是免费的 — 你所需要关心的是支持合同。如果你在考虑开源的虚拟化操作系统或软件，确保你已计算了支持方面的开销。如果支持费用与该软件的虚拟化实例数量有关，最好是把花费最大的部分放到专用服务器上运行以节省费用。记住，硬件相对于软件许可及/或服务支持费用而言那是相当小，这一点很重要。计算硬件成本的时候，确保也计算了硬件的维护、耗电、制冷和机架空间所需的费用。
虚拟化技术本身也需要考虑许可和支持。好消息是所有的主流的虚拟化玩家都有某些免费的方案供你起步。即便在一年前，由于VMware几乎是仅有的玩家，免费的虚拟化还是不可能的，不过现在VMware, Microsoft, Xen Source, 和Virtual Iron都有了免费的解决方案了。
]]></description>
			<content:encoded><![CDATA[<h4>什么是虚拟化，为什么要虚拟化？</h4>
<p>虚拟化是在单个物理服务器上运行多个独立的虚拟操作系统的一种方法。是通过最大化物理资源来达到投资最大化的一种途径。既然摩尔定律已经准确地预测出计算能力的指数增长，而对于同样的计算任务而言，硬件需求大部分没有改变,那么现在，把一台极其廉价的双槽双核1U机架式服务器，拆分为8个乃至16个虚拟服务器就已经变得可行了。虚拟化技术是获得更高服务器密度的一种方式。不过，实际上它并没有提升总体的计算能力；其实由于额外开销，计算能力还略有下降。但是，由于一台现代的3000美元2插槽4核服务器，比4年前30000美元的8插槽8核服务器还要强大，我们就可以通过在这种新硬件上增加逻辑操作系统的数量来开发它的能力。这可以削减主要的硬件购置和维护费用，从而最终显著地节省公司或组织的成本。</p>
<h4>什么时候该虚拟化？</h4>
<p>虚拟化是中小规模应用的完美解决方案。虚拟化不应该用在那些需要1到多台服务器进行集群方能满足需求的高性能应用上，因为增加的开销和复杂性只会降低性能。基本上我们是在拿一个12GHz（3GHz的四核CPU）的服务器来把它拆解为 16个750MHz的服务器。不过一旦有8个那样的服务器处于非忙时或空闲时，其余的8个服务器将能得到约1.5GHz的主频。</p>
<p>尽管在虚拟化行业里面有人喜欢宣扬高CPU利用率作为硬件优化使用的指标，这种建议不应该走极端，在应用的响应性超限了还使用。一个简单的经验法则是，永远也不要让服务器的CPU利用率在峰值负荷的情况下超过50%；更为重要的是，永远不要让应用的响应时间超过合理的SLA （服务水平协议） 。 大部分内部使用的先进服务器的任务是把CPU利用率控制在1-5%之间 。在单台物理服务器上运行8个操作系统会把峰值CPU利用率提高到将近50% ，但平均水平要低得多，因为虚拟操作系统的波峰波谷,或多或少地,会趋于相互抵消。</p>
<p>尽管在今天现有大部分的虚拟化解决方案里，出现CPU过载的很少，但存储及网络吞吐量的I/O（输入/输出）过载则是另一回事。对于有着高到极端的存储或硬件I/O需求的服务器来说，运行于裸机之上会更为明智一些，即便其CPU需求可在虚拟环境中得到满足。</p>
<h4>如何避免“所有鸡蛋都放在一个篮子上”综合症</h4>
<p>虚拟化最大的忧虑是出现“所有鸡蛋放进同一篮子”综合症。把所有关键服务器都放进一台物理服务器是不是明智之举？当然不是！避免这种倾向的最简易的办法是确保单个服务没有驻留在单台服务器上。我们以下列服务器类型为例说明：</p>
<ul>
<li>HTTP </li>
<li>FTP </li>
<li>DNS </li>
<li>DHCP </li>
<li>RADIUS </li>
<li>LDAP </li>
<li>使用光纤通道（FC）或iSCSI存储的文件服务storage </li>
<li>Active Directory服务 </li>
</ul>
<p>我们可以将这些类型的服务器中的每一个放置到至少2台物理服务器上，以便获得冗余性。这种类型的服务，由于在单台服务器失效的时候可方便地切换，相对而言比较易于集群。当单台物理服务器失败或需要进行服务的时候，在其他物理服务器上的另外的虚拟服务器会自动接替。通过横跨多台物理服务器，这些关键服务永远也不会因为单个硬件失败而停止运行。</p>
<p>对于像Exchange Server，Microsoft SQL ,MySQL或Oracle这样更为复杂的服务，集群技术可应用于在两台物理服务器上的两个逻辑服务器的同步；这种方法在转换的时候一般会导致约5分钟的停机时间。但这并非由于虚拟化，而是因为集群的复杂性往往需要时间去进行转换。处理这些复杂服务的一种替代办法,是把虚拟服务器从主物理服务器迁移至另一台物理服务器。为了让这个方法行之有效，需要不断地将内存从一台物理服务器同步到另一台，以便故障切换时间能在毫秒级的时间内完成，这样所有服务都能维持正常运行。</p>
<h4>物理服务器向虚拟服务器的迁移</h4>
<p>任何一个像样的虚拟化解决方案都会提供某种类型的P2V（物理到虚拟）迁移工具。该P2V工具会对一台已有的物理服务器的驱动器堆栈做一些必要的修改，来进行硬盘镜像的虚拟化，以便服务器可以虚拟服务器的形式进行启动和运行。这么做的好处是不必重建服务器，再人工把它们配置为虚拟服务器 — 只需原封不动地把服务器接收过来就行！</p>
<p>因此，如果你的数据中心充斥着主频低于GHz的日渐老化的服务器的话，它们正是P2V迁移的绝佳候选者。由于这些授权你已支付，你甚至无需为获取授权的成本担忧。你几乎可以腾出128台主频不过GHz的传统服务器的空间，让位于8台1U高的双槽四核服务器，服务器带双千兆以太网卡以及两套独立的iSCSI磁盘阵列，均通过千兆以太网交换机互联到一起。每年在老系统上花费的的硬件维护费足够支付购买这里所有的新硬件！尽管想象一下吧，进行这样的迁移之后，你的服务器空间会有多整洁。新硬件可全部装进一个机架中，给你腾出了大量的扩展空间。</p>
<p>作为虚拟化的一个额外的好处，你可以得到一个灾难恢复计划，因为虚拟化后的镜像可悲用于实时恢复所有服务器。自问一下，如果是传统的服务器的死掉的话会发生什么事情。你还记不记得如何从潦草的记录中去重建并重新配置回所有的服务器？（我想你现在就要哭出来了。）利用虚拟化，通过P2V镜像重建虚拟服务器，你可以在1个小时之内恢复Active Directory和Exchange Server。</p>
<h4>虚拟服务器的补丁管理</h4>
<p>虚拟服务器的补丁管理与正常服务器的并没有什么不同，因为每个虚拟操作系统就是自己独立的虚拟硬盘。你仍需要一个补丁管理系统来对所有服务器进行打补丁,不过未来可能会出现有趣的发展，如果服务器共享某些公共的操作系统或应用二进制代码的话，也许可以对多个操作系统同时打补丁。理想情况下，你可以为独立的或一组类似的服务器分配一种补丁级别。目前，还还需要像在其他操作系统上做过那样对虚拟操作系统进行打补丁，不过在虚拟化领域将有所创新，而你在物理服务器上是做不到这些的。</p>
<h4>授权与支持方面的考虑</h4>
<p>软件的许可是虚拟化的一大担忧。 谁都不想为运行于单台服务器上的16个虚拟会话支付16份许可。（高昂的）软件许可通常会令硬件开销相形见绌，因此在共享的硬件上运行一份许可为2万美元的软件是愚蠢的。这种情况下，最好是在速度最快的物理服务器上跑软件，不要进行任何虚拟化，以便增加开销。</p>
<p>对于像Windows Server 2003标准版这类的软件，需要为运行在物理服务器上的每个虚拟会话支付费用。此规则的例外是企业版，允许运行在1台物理机器上以1份许可分费用运行Windows Server 2003的4分虚拟拷贝。微软的这项许可策略应用于以Windows Server 2003为操作系统的任何虚拟技术上。</p>
<p>如果你用的是开源软件，就不必担心许可问题，因为它一直就是免费的 — 你所需要关心的是支持合同。如果你在考虑开源的虚拟化操作系统或软件，确保你已计算了支持方面的开销。如果支持费用与该软件的虚拟化实例数量有关，最好是把花费最大的部分放到专用服务器上运行以节省费用。记住，硬件相对于软件许可及/或服务支持费用而言那是相当小，这一点很重要。计算硬件成本的时候，确保也计算了硬件的维护、耗电、制冷和机架空间所需的费用。</p>
<p>虚拟化技术本身也需要考虑许可和支持。好消息是所有的主流的虚拟化玩家都有某些免费的方案供你起步。即便在一年前，由于VMware几乎是仅有的玩家，免费的虚拟化还是不可能的，不过现在VMware, Microsoft, Xen Source, 和Virtual Iron都有了免费的解决方案了。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.acmind.com/archives/902/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>2M带宽的网站或服务器可有多少用户同时浏览网站而不进行下载</title>
		<link>http://blog.acmind.com/archives/221</link>
		<comments>http://blog.acmind.com/archives/221#comments</comments>
		<pubDate>Thu, 05 Feb 2009 16:00:14 +0000</pubDate>
		<dc:creator>笑谈</dc:creator>
				<category><![CDATA[学习应用]]></category>
		<category><![CDATA[2M]]></category>
		<category><![CDATA[带宽]]></category>
		<category><![CDATA[下载]]></category>
		<category><![CDATA[网站]]></category>
		<category><![CDATA[用户]]></category>
		<category><![CDATA[服务器]]></category>
		<category><![CDATA[浏览]]></category>

		<guid isPermaLink="false">http://blog.acmind.com/?p=221</guid>
		<description><![CDATA[提问：2M带宽的网站或服务器可有多少用户同时浏览网站而不进行下载，且感觉不会很卡，再最多可供多少用户同时浏览网站不下载
最佳答案
2M带宽是指下行的带宽(下载速度2Mbit)，算下就是下载2048KB/8 = 256 KB/S    2M带宽对应的上行速度可能是512KBit吧(就是64KB的上传速度)。     一个页面不卡的话差不多要100K速度,所以支持3、4个用户同时打开个页面。如果页面不大，可以支持更多的用户。     自己算下吧。
&#160;
其他回答&#160;&#160;&#160; 共 4 条

如果你只有一个网页，网页总大小（包括里面的图片、CSS文件等）一共是200Kb,在不限制IIS并发连接数的情况下，    可以同时有20000/200=100个连接，     因为浏览一个网页时，先要把网页的内容下载到本地的临时文件夹下，才能访问。     因为一般情况下，不可能是100个人同时访问的，除非你是大门户网站。
&#160;

你说的2M带宽如果是adsl拨号往下看    2M的ADSL上行带宽只有到512k~1m，转换成上传速率不到50kb/s。     如果网站页面小也就最多支持两三个同时人访问。
&#160;

ADSL属于冗余带宽 虽然不太好 也不会那么不济 承载几十个同线路的访问不太频繁的用户访问也不会觉的太卡，其实这个主要是看网站程序 和客户访问所需要的带宽。不一定的。
&#160;

上面大家回答的比较全面了，关键的一点你没考虑：你每天开着电脑的电费，足够你支付一个简单的域名和空间了，那可是真正的网站。
]]></description>
			<content:encoded><![CDATA[<p>提问：2M带宽的网站或服务器可有多少用户同时浏览网站而不进行下载，且感觉不会很卡，再最多可供多少用户同时浏览网站不下载</p>
<p>最佳答案</p>
<p>2M带宽是指下行的带宽(下载速度2Mbit)，算下就是下载2048KB/8 = 256 KB/S    <br />2M带宽对应的上行速度可能是512KBit吧(就是64KB的上传速度)。     <br />一个页面不卡的话差不多要100K速度,所以支持3、4个用户同时打开个页面。如果页面不大，可以支持更多的用户。     <br />自己算下吧。</p>
<p>&#160;</p>
<p>其他回答&#160;&#160;&#160; 共 4 条</p>
<p><a name="263846603"></a></p>
<p>如果你只有一个网页，网页总大小（包括里面的图片、CSS文件等）一共是200Kb,在不限制IIS并发连接数的情况下，    <br />可以同时有20000/200=100个连接，     <br />因为浏览一个网页时，先要把网页的内容下载到本地的临时文件夹下，才能访问。     <br />因为一般情况下，不可能是100个人同时访问的，除非你是大门户网站。</p>
<p>&#160;</p>
<p><a name="263848830"></a></p>
<p>你说的2M带宽如果是adsl拨号往下看    <br />2M的ADSL上行带宽只有到512k~1m，转换成上传速率不到50kb/s。     <br />如果网站页面小也就最多支持两三个同时人访问。</p>
<p>&#160;</p>
<p><a name="263872385"></a></p>
<p>ADSL属于冗余带宽 虽然不太好 也不会那么不济 承载几十个同线路的访问不太频繁的用户访问也不会觉的太卡，其实这个主要是看网站程序 和客户访问所需要的带宽。不一定的。</p>
<p>&#160;</p>
<p><a name="263896601"></a></p>
<p>上面大家回答的比较全面了，关键的一点你没考虑：你每天开着电脑的电费，足够你支付一个简单的域名和空间了，那可是真正的网站。</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.acmind.com/archives/221/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

