<?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>Malaysia VMware Communities &#187; dc</title>
	<atom:link href="http://malaysiavm.com/blog/tag/dc/feed/" rel="self" type="application/rss+xml" />
	<link>http://malaysiavm.com/blog</link>
	<description></description>
	<lastBuildDate>Mon, 21 Nov 2011 15:50:35 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
		<item>
		<title>Why ESX are not suitable to run on Blade</title>
		<link>http://malaysiavm.com/blog/why-esx-are-not-suitable-to-run-on-blade/</link>
		<comments>http://malaysiavm.com/blog/why-esx-are-not-suitable-to-run-on-blade/#comments</comments>
		<pubDate>Tue, 30 Sep 2008 06:21:24 +0000</pubDate>
		<dc:creator>craig</dc:creator>
				<category><![CDATA[Data Center]]></category>
		<category><![CDATA[Hardware]]></category>
		<category><![CDATA[Blade]]></category>
		<category><![CDATA[CPU]]></category>
		<category><![CDATA[Data Ceter]]></category>
		<category><![CDATA[dc]]></category>
		<category><![CDATA[Dell]]></category>
		<category><![CDATA[ESX]]></category>
		<category><![CDATA[Memory]]></category>
		<category><![CDATA[Servers]]></category>
		<category><![CDATA[VM]]></category>
		<category><![CDATA[VMware]]></category>

		<guid isPermaLink="false">http://malaysiavm.com/blog/?p=364</guid>
		<description><![CDATA[1st of all, the reason of being utilize blade system in the market are looking at the point of servers consolidation, reduce power consumption and reduce the TCO require to purchase in term of hardware compare to the 1U, 2 U and 4 U servers. When we do compare the reason of having blade, you [...]]]></description>
			<content:encoded><![CDATA[<p>1st of all, the reason of being utilize blade system in the market are looking at the point of servers consolidation, reduce power consumption and reduce the <a href="http://www.malaysiavm.com/blog/tag/tco">TCO</a> require to purchase in term of hardware compare to the 1U, 2 U and 4 U servers. When we do compare the reason of having blade, you will always notice it was comparable between 2U and 1U servers in the x86 family and data center environment. In large scale deployment, you will always see that the Blade allow you to scale and spend in the sense with more stand alone machine you can have with the limitted rack space and power you do have in your <a href="http://malaysiavm.com/blog/tag/dc">DC</a>. These seems to make sense for us to start moving to blade, BUT it also have some risk which will become major issue later on.</p>
<p>Before you can use blade, you require higher <a href="http://malaysiavm.com/blog/tag/power">power</a> consumption per rack to support approximately 30 to 32 blades per racks on 42 servers rack. At the same time, the cooling unit design in you DC require to be customize to ensure your <a href="http://malaysiavm.com/blog/tag/blade">blade</a> chassis is working in perfect condition. Once you have this, then you may able to start think about Blade.</p>
<p><span id="more-364"></span></p>
<p><a href="http://malaysiavm.com/blog/tag/esx">ESX</a> on Blade have been some idea I personally thought before. The products I specify looking is the latest <a href="http://malaysiavm.com/blog/tag/dell">DELL</a> Blade M1000e. The power and cooling in my DC is not a big issue. When I do analyzed the possibilities, I found couple of show stopper to deny my decision to move forward on that. As the enterprise architect point of view, <a href="http://malaysiavm.com/blog/tag/blade">Blade</a> will be more suitable to consolidate those machine which require to run on physical VS Virtualization. The reason of that, is not really the matter of CPU or Memory you can have in the single blade, is really about the redundancy and performance we focusing on our virtualization. The limited number of pass through, NIC, and FC per blade is really not able to meet the number of <a href="http://www.malaysiavm.com/blog/tag/vm">VM</a> we tried to achieve per host. We require redundancy, teaming as well as performance through put in term of networking and storage with the ESX servers we have. When we do calculate in term of cost per VM, the number had not show up as significant saving as we expected.</p>
<p>In additional to that, the more <a href="http://www.malaysiavm.com/blog/tag/esx">ESX</a> machine we have in our Virtualization farm, it always require additional efforts to manage it for long term basis. There are many cases that users had built the ESX server with only 2 gigabits NIC for VMnetwork, which end up facing the performance issue in term on the Networking as well as the single point of failure. Virtualization is not performance sacrification. If we do plan properly, we will gain performance in virtualization vs under utilization physical machine.</p>
<p>Here is those finding I have and I will say that the <a href="http://www.malaysiavm.com/blog/tag/blade">Blade</a> will not fit the virtualization requirement to achieve High availability and performance requirement. If we will have enough money to be spent on Blade environment, I believe you should have sufficient budget to go for something more suitable like R900, R905 and others 4U servers which provide more <a href="http://malaysiavm.com/blog/tag/memory">memory</a> and <a href="http://malaysiavm.com/blog/tag/cpu">CPU</a> you need.</p>
]]></content:encoded>
			<wfw:commentRss>http://malaysiavm.com/blog/why-esx-are-not-suitable-to-run-on-blade/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>ESX &amp; VM Networking Concepts</title>
		<link>http://malaysiavm.com/blog/esx-vm-networking-concepts/</link>
		<comments>http://malaysiavm.com/blog/esx-vm-networking-concepts/#comments</comments>
		<pubDate>Thu, 04 Sep 2008 01:34:05 +0000</pubDate>
		<dc:creator>craig</dc:creator>
				<category><![CDATA[Data Center]]></category>
		<category><![CDATA[Virtualization]]></category>
		<category><![CDATA[datacenter]]></category>
		<category><![CDATA[dc]]></category>
		<category><![CDATA[ESX]]></category>
		<category><![CDATA[Networking]]></category>
		<category><![CDATA[virtual]]></category>
		<category><![CDATA[VM]]></category>

		<guid isPermaLink="false">http://malaysiavm.com/blog/?p=212</guid>
		<description><![CDATA[This topic is specifically talk about the networking concept in VM infrastructure. In most of the cases we discuss and Virtualization and Consolidation, we always thought about number of servers we reduce in the data center, the powers we save as well as others facts. Some how, I could see most of the users today [...]]]></description>
			<content:encoded><![CDATA[<p>This topic is specifically talk about the networking concept in <a href="http://malaysiavm.com/blog/tag/vm">VM</a> infrastructure. In most of the cases we discuss and Virtualization and Consolidation, we always thought about number of servers we reduce in the data center, the powers we save as well as others facts. Some how, I could see most of the users today who may had already in the production for little while, and will start realize about some performance issues from the network, storage and servers perspective. WIth that particular challenges and reason, we start to hear these groups are trying to tell the customers or users, if you do want to run it on VM, it meant there is performance scarification.</p>
<p>I am strongly disagreed with these comments as most of us know that the reason of consolidate and virtualization, is not for performance reduce, is really to improve efficiency and utilization of the hardware that we purchased. Networking play a big parts in <a href="http://malaysiavm.com/blog/tag/vm">VM</a> infrastructure and most of the time, it did become the performance bottle neck for most users. Let me talk about some example below.</p>
<p>1 of the case i saw here, which the engineer configure it&#8217;s <a href="http://malaysiavm.com/blog/tag/esx">ESX</a> in to a server which only have 2 physical NIC connected for VMnetwork interface to allow VM to be connected to the production network. There is more than 10 VMs on the <a href="http://malaysiavm.com/blog/tag/esx">ESX</a> servers which connected to the 2 gigabits NIC and share among each others. In physical environment, for 10 physical servers, they always get 1gb per servers and is not in shared condition. But now, since virtualized, they need to share 2gb with 10 <a href="http://malaysiavm.com/blog/tag/vm">VM</a>. Guess what, the users start complaining slow performance on the network file transfer, the backup through Network is slow as well as any reason that the network slowing down due to the high peak bandwidth utilization from any of the VM which shared on the 2 NICs. Not only the NIC causing the performance issues, and the switches uplink to the <a href="http://malaysiavm.com/blog/tag/dc">DC</a> switches had also another thing you may need to keep an eye on. No matter how many gigabits connection you connected your servers through, it will still depend of the total uplink for your switches to route the traffic to the DC.</p>
<p>In this case, they not really figure out the performance issues as they won&#8217;t notice this performance bottleneck in the performance chart from <a href="http://malaysiavm.com/blog/tag/virtual">Virtual</a> Center. Most of the time, only the network guys will able to identified these issues. It really hit hard to some of the engineer which push hard on the virtualization, but it did become performance sacrification to the customers at the end. I will not want this to happen for myself, as we had invested SAN storage &amp; High capacity servers which is not cheap solution.</p>
<p><span id="more-212"></span></p>
<p>Therefore, I will recommend that to deploy the VM Infrastructure in to enterprise environment in <a href="http://malaysiavm.com/blog/tag/datacenter">Data Center</a>, we should always plan ahead including the Networking conditions. Again, Virtualization not meant performance sacrification, and virtualization do provide a lot of benefits which physical servers don&#8217;t.</p>
]]></content:encoded>
			<wfw:commentRss>http://malaysiavm.com/blog/esx-vm-networking-concepts/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.340 seconds -->

