<?xml version="1.0" encoding="utf-8"?>

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		<title>ADSM.ORG - Blogs</title>
		<link>http://adsm.org/forum/blog.php</link>
		<description>IBM Tivoli iTSM, TSM, ADSM Technical Discussion Forum</description>
		<language>en</language>
		<lastBuildDate>Sat, 25 May 2013 15:55:28 GMT</lastBuildDate>
		<generator>vBulletin</generator>
		<ttl>60</ttl>
		<image>
			<url>http://adsm.org/forum/images/misc/rss.jpg</url>
			<title>ADSM.ORG - Blogs</title>
			<link>http://adsm.org/forum/blog.php</link>
		</image>
		<item>
			<title>Q file</title>
			<link>http://adsm.org/forum/entry.php?33-Q-file</link>
			<pubDate>Tue, 18 Sep 2012 15:34:00 GMT</pubDate>
			<description>Can anyone provide me with a script, or show me how to, list all of the files that are backed up in a node.  Running on aix platform.  
 
Thanks in...</description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore">Can anyone provide me with a script, or show me how to, list all of the files that are backed up in a node.  Running on aix platform. <br />
<br />
Thanks in advance for any and all help?</blockquote>

]]></content:encoded>
			<dc:creator>apwurtsm</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?33-Q-file</guid>
		</item>
		<item>
			<title>TSM client backup taking long time to finish</title>
			<link>http://adsm.org/forum/entry.php?32-TSM-client-backup-taking-long-time-to-finish</link>
			<pubDate>Tue, 12 Apr 2011 17:19:05 GMT</pubDate>
			<description>tsm backup tking long time to finish. 
  
we have configured the backup go to disk but it waiting for offline media at a instance . 
  
is it...</description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore">tsm backup tking long time to finish.<br />
 <br />
we have configured the backup go to disk but it waiting for offline media at a instance .<br />
 <br />
is it possible for backup to take other tape mgmt class even though it bind to disk class</blockquote>

]]></content:encoded>
			<dc:creator>dkarpe</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?32-TSM-client-backup-taking-long-time-to-finish</guid>
		</item>
		<item>
			<title>is TSM really the best?</title>
			<link>http://adsm.org/forum/entry.php?16-is-TSM-really-the-best</link>
			<pubDate>Tue, 07 Dec 2010 14:41:17 GMT</pubDate>
			<description>---Quote (Originally by rwhtmv)--- 
So the boss now says to evaluate ANNUALLY all of what we use, and provide insight to other products, and why we...</description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore"><div class="bbcode_container">
	<div class="bbcode_quote">
		<div class="quote_container">
			<div class="bbcode_quote_container"></div>
			
				<div class="bbcode_postedby">
					<img src="images/misc/quote_icon.png" alt="Quote" /> Originally Posted by <strong>rwhtmv</strong>
					<a href="showthread.php?p=94452#post94452" rel="nofollow"><img class="inlineimg" src="images/buttons/viewpost-right.png" alt="View Post" /></a>
				</div>
				<div class="message">So the boss now says to evaluate ANNUALLY all of what we use, and provide insight to other products, and why we do NOT use them.  I just love micro-management.  However, there are a few items with TSM that I have always wondered about.  Please address these if you have a way to resolve them, or have found a workaround.<br />
<br />
1.  When a node is backing up and I have to CANCEL SE for whatever reason:  how to know (other than file property inspection or dsmsched.log browsing and guessing) what is left to backup from that node that was missed due to the cancelled session.  Is there a way to view the journal logs, or extract the information from the client, since it pre-scanned the filespace and knows what it intends to capture?<br />
<br />
2.  What is the best reporting tool/dashboard you have used?  Most of the built-in stuff is just not good enough.  Something to keep the boss happy with pretty information he doesn't understand.<br />
<br />
3.  Why is this true?:  Node connected to T1 circuit with nothing using it except TSM client session doing a backup.  No noise on the line, can move data via FTP at good speed.  TSM server has only 1 session, and no procs running, quad core proc.  Writes backup to tier 1 disk with plenty of performance to avoid bottlenecks.  (Migrations zoom from disk to tape.)  So....start a backup from ANY version of TSM client (tried them all).  Client sends the files at nothing close to the speed it should.  Node is also quad core, with no performance hit.  I'm not talking about the aggregate speed, either, just plain old backup speed.  Please refrain yourself from saying &quot;Defrag&quot;.  That is not it.</div>
			
		</div>
	</div>
</div></blockquote>

]]></content:encoded>
			<dc:creator>rwhtmv</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?16-is-TSM-really-the-best</guid>
		</item>
		<item>
			<title>V6.1.3 is out</title>
			<link>http://adsm.org/forum/entry.php?12-V6-1-3-is-out</link>
			<pubDate>Mon, 04 Jan 2010 06:56:07 GMT</pubDate>
			<description>theres a new client version available 
 
get it from 
ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/client/v6r1</description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore">theres a new client version available<br />
<br />
get it from<br />
<a href="ftp://ftp.software.ibm.com/storage/tivoli-storage-management/maintenance/client/v6r1" target="_blank">ftp://ftp.software.ibm.com/storage/t...ce/client/v6r1</a></blockquote>

]]></content:encoded>
			<dc:creator>svrmarty</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?12-V6-1-3-is-out</guid>
		</item>
		<item>
			<title>TCP Protocol Optimization and WAN Optimization</title>
			<link>http://adsm.org/forum/entry.php?9-TCP-Protocol-Optimization-and-WAN-Optimization</link>
			<pubDate>Fri, 11 Dec 2009 19:42:31 GMT</pubDate>
			<description>In addition to some of the other technologies already discussed in other blog articles here, such as Byte Caching, Object Caching and Compression,...</description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore">In addition to some of the other technologies already discussed in other blog articles here, such as Byte Caching, Object Caching and Compression, TCP Protocol Optimization is another key technology used by WAN Optimization Appliances.<br />
<b><br />
What is Protocol Optimization?</b><br />
<br />
Protocol Optimization is the use of in-depth protocol knowledge to accelerate user response time. By understanding the intricacies of how specific protocols function, WAN Optimization appliances can anticipate<br />
user requests, which results in data being retrieved before clients request it. For applications in which requests are typically serialized (HTTP, CIFS, data backup and restore), or for traditionally “chatty” applications originally designed for<br />
LANs (CIFS, MAPI), the performance improvement gained by Protocol Optimization can be considerable.<br />
<br />
<b>Why should I perform Protocol Optimization in my network?</b><br />
In today’s enterprise, latency has become a bottleneck to user productivity. Whether delays are due to remote Web based applications or high-latency protocols such as MAPI and CIFS that typically experience degradation when accessed across a WAN, Protocol Optimization can greatly improve performance. When discussing latency, it<br />
is important to understand that while bandwidth can sometimes be a factor (if your WAN is constrained), latency is more commonly caused by the sheer number of roundtrips required to satisfy a request.<br />
All the WAN Optimization techniques together can effectively minimize delays associated with waiting for data retrieval by anticipating user requests. The result is that when clients make a request, the data can be served at LAN speed instead of WAN speed. This allows users to stop waiting for data retrieval and start being more productive.<br />
<b><br />
How does Protocol Optimization work?</b><br />
Protocol Optimization is possible because SG appliances have the unique ability to terminate user requests. Many vendors simply repeat the exact same request made by the client, with no real intelligence<br />
about the how the protocol actually works.  Blue Coat's ProxySG appliance, however, terminates the request from the client as if it was the server and opens a separate connection to the server that allows it to intelligently make requests on behalf of the client. As a result, ProxySG appliances apply Protocol Optimization to many of the protocols that they terminate. This includes HTTP, HTTPS, CIFS, MAPI, FTP, MMS, and RTSP. <br />
<b><br />
CIFS Optimization – Read Ahead and Write Back</b><br />
For enterprises accelerating CIFS, Blue Coat’s WAN Optimization technology has the ability to reduce user response time by implementing Read Ahead and Write Back. The biggest problem generally associated with CIFS is that the Windows client read is often limited to 4KB. While requesting a file with 4KB reads over the LAN may not be<br />
noticeable, accessing the same file over the WAN can be painful. To minimize the effects of this client limitation, ProxySG appliances take advantage of the ability of the CIFS protocol to support 60KB reads. When a client read request is received, the appliance anticipates future reads and makes a 60KB bulk request, or Read Ahead, thus saving<br />
numerous round trips to the server. Write Back is the method used to minimize response time when a user is writing (saving) a file to a server. Most often, the latency associated with writing a file to a server is due to the acknowledgements required from the server in order for the client to continue sending additional data. With Write<br />
Back, the ProxySG appliance acknowledges the data as if it was the server, decoupling the communications between client and server, allowing the client to write the file with little to no latency.<br />
<br />
<b>CIFS Example</b><br />
Consider a client attempting to request a 20MB file over the WAN. If the CIFS client read is limited to 4KB, the client will require over 5000 reads to retrieve the entire file. Over the LAN, the delay per round-trip will not be a significant portion of the transfer time, but requesting this same file over a WAN with 300ms latency will take 25 minutes! With a ProxySG appliance deployed, Protocol Optimization is able to retrieve this file quickly by anticipating the many<br />
requests that would be necessary to retrieve the entire file. Instead of making hundreds or thousands of requests as the client is required to do, the SG appliance is able to read the data in large chunks instead. The result is that the ProxySG appliance is able to retrieve this file over the same WAN in less than 2 minutes.<br />
<br />
<b><br />
The Blue Coat Difference</b><br />
<br />
Because Blue Coat ProxySG appliances are application proxies, they have the ability to maintain application level persistent connections on both the client and server-side connection. This results in less time spent creating and tearing down connections, effectively reducing latency even further.</blockquote>

]]></content:encoded>
			<dc:creator>TimC</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?9-TCP-Protocol-Optimization-and-WAN-Optimization</guid>
		</item>
		<item>
			<title>WAN Optimization and Network Appliance SnapMirror</title>
			<link>http://adsm.org/forum/entry.php?7-WAN-Optimization-and-Network-Appliance-SnapMirror</link>
			<pubDate>Thu, 21 May 2009 18:57:01 GMT</pubDate>
			<description>Organizations collect vast amounts of information, and storing it all is only the first challenge in comprehensive data management. NetApp’s...</description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore">Organizations collect vast amounts of information, and storing it all is only the first challenge in comprehensive data management. NetApp’s SnapMirror application is a popular choice to automate the backup, duplication and recovery of data to ensure availability in the event of a disaster or user error. Quite often, that involves replicating large amounts of data across a wide area network.<br />
<br />
WAN links, however, have higher latency and much less bandwidth than either a LAN or Fibre Channel network. Latency severely impacts the performance of protocols SnapMirror relies on for WAN communication, and the amount of data often dwarfs the bandwidth most organizations<br />
can afford. Even using SnapMirror’s advanced differential backup techniques, the amount of data blocks touched on an array can still be significant, and much larger than can be moved across the WAN during the backup window. If differential backups take hours, and a mirror initialization takes days or longer, how can organizations effectively maintain backups? Or worse, how can they expect to restore them quickly in a real disaster?<br />
<br />
The technologies in WAN Optimization <br />
can significantly improve SnapMirror data transfers. WAN Optimization uses byte caching and compression, combined with TCP enhancements and bandwidth<br />
management to achieve remarkable savings across the WAN.  <br />
<br />
Mirror initialization triggers a<br />
massive amount of network traffic which is highly repetitive and very compressible. Differential Mirror updates also contain much repetition; although the data is new in each individual file block, the byte patterns between files are very redundant and respond well to compression and caching. Initialization, recovery, and update times are typically decreased by 90% with WAN Optimization deployments.<br />
<br />
Blue Coat offers one solution which goes beyond just compression and protocol optimization, however, by providing bandwidth management to control access to network resources. Blue Coat's ProxySG appliances can prioritize traffic based on user, application, time of day and content, ensuring that SnapMirror gets the bandwidth it needs both during the backup<br />
window, and in the event of an emergency restore.<br />
<br />
Tests conducted in labs and within customers environments show that WAN Optimization significantly improves the performance of SnapMirror in real world scenarios. In one test, the time needed to finish a Mirror backup operation was reduced by 58% on the first (cold) pass, and subsequent backups by almost 90%. Bandwidth used to complete the backup or restore was also reduced by 85%. Such a dramatic improvement makes it possible for our customers to complete their backups within the nightly window again.<br />
<br />
For a new mirror initialization, WAN Optimization reduced the overall time to clone by 41x; convenient for IT when creating mirrors, but that performance increase would be critical in the event of an actual restore due to data loss or disaster.</blockquote>

]]></content:encoded>
			<dc:creator>TimC</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?7-WAN-Optimization-and-Network-Appliance-SnapMirror</guid>
		</item>
		<item>
			<title>Compression Technology in WAN Optimization</title>
			<link>http://adsm.org/forum/entry.php?6-Compression-Technology-in-WAN-Optimization</link>
			<pubDate>Tue, 12 May 2009 18:52:25 GMT</pubDate>
			<description>Another commonly used technology in WAN Optimization is Compression. 
 
*What is Compression?* 
 
Compression is the reduction in size of data by...</description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore">Another commonly used technology in WAN Optimization is Compression.<br />
<br />
<b>What is Compression?</b><br />
<br />
Compression is the reduction in size of data by converting it to a format that requires fewer bits. Most often compression is used to minimize storage space (on a hard drive, for example) or for reducing transmitted data over a network. By reducing the size of data transferred, more bandwidth is available and transmission times are reduced. <br />
<br />
<b>Why should I perform Compression in my network?</b><br />
<br />
Compression technologies are designed to significantly improve bandwidth utilization by minimizing the amount of data traversing the network. Compression can be used in appliances which are deployed as part of a WAN Optimization solution.  For WAN Optimization solutions, appliances on each side of the WAN use the ADN (Application Delivery Network) to transfer compressed data between them. This is useful for requests originating at branch offices to servers at the core, but can be even more beneficial for backups that must occur regularly over the WAN.<br />
<br />
<b>How does Compression work?</b><br />
Compression technology uses algorithms to remove extraneous/repetitive information. After compression is applied, the original information is represented by a more compact and efficient format. This “compressed” payload can then be sent over the network. After the compressed data is received at the destination, it is uncompressed based on extraction algorithms. One well known appliance uses the industry standard gzip/deflate algorithm to compress data.<br />
<br />
<b>ADN Compression</b><br />
ADN Compression enables organizations to fully extract every performance benefit available when sending data through an ADN tunnel between appliances. ADN tunnels require that  appliances on opposite sides of the WAN be members of the same ADN network and that the upstream appliance either be advertising routes to servers to be accessed by appliances on the opposite side of the WAN, or be deployed inline so that transparent ADN tunnels are possible. Traffic accelerated between clients and servers is automatically compressed before being sent through the ADN tunnel, decreasing bandwidth usage and optimizing response time to the end user. ADN Compression is often used in conjunction with Byte Caching and Object Caching to achieve optimum results. In the case of Byte Caching and Compression, Byte Caching is first applied to the data and then the resulting data is compressed. Both features are enabled by default to optimize ADN directed traffic. ADN Compression for any arbitrary protocol can also be configured on the Blue Coat ProxySG using policy; it can also be controlled separately for both inbound and outbound traffic on the WAN.</blockquote>

]]></content:encoded>
			<dc:creator>TimC</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?6-Compression-Technology-in-WAN-Optimization</guid>
		</item>
		<item>
			<title>Byte Caching</title>
			<link>http://adsm.org/forum/entry.php?5-Byte-Caching</link>
			<pubDate>Thu, 30 Apr 2009 20:32:25 GMT</pubDate>
			<description><![CDATA[In our last post we talked about caching technologies in general and then focused on object caching.  Now we'll do a drill down into byte caching. 
...]]></description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore">In our last post we talked about caching technologies in general and then focused on object caching.  Now we'll do a drill down into byte caching.<br />
<br />
Where object caching falls short, byte caching takes over. Byte Caching caches TCP traffic<br />
irrespective of application level protocol, port, or IP address, on both ends of the WAN link.<br />
<br />
<b>How byte caching works</b><br />
<br />
Typically two WAN Optimization appliances are deployed, one on each end of a WAN link. Both the appliances maintain a cache of all TCP traffic over the WAN link. Each time data needs to be sent over the WAN link, it is scanned for duplicate segments in the cache. If any duplicates are found, the duplicate data (as much as 64KB), is removed from the byte sequence, and a token and a reference to the cache location is inserted (typically a 12 byte package). On the receiving end, the token and the reference are removed from the byte sequence and original data is inserted by<br />
reading from the cache thus creating a byte sequence identical to the original byte sequence.<br />
<br />
<b>How does it help?</b><br />
<br />
Up to 90% of WAN traffic is repetitive. The reason for this is that most of the enterprise traffic comprises of the following:<br />
<br />
1. Web application traffic – All the users at the branch use same or similar web applications. Each interaction with these applications results in WAN traffic that is marginally different than the traffic for previous interactions resulting in resending of same bytes as before.<br />
<br />
2. File server traffic (data storage management solutions as well) – File traffic makes several round trips over the WAN while the user is working on a file. The typical office applications save copies of the file at small intervals resending only slightly modified versions of the same document over the WAN link.<br />
<br />
3. Email traffic – Enterprise emails are frequently addressed to several people. For each recipient in the branch a copy of email travels over the WAN. Replies to emails contain repetitive data resulting in further redundant traffic over the WAN.<br />
<br />
<br />
By eliminating redundant traffic we can expect to effectively increase WAN capacity 10 to 20<br />
times depending on the application. Byte caching works at the TCP layer and does not depend on any knowledge of the application to cache the traffic. This allows byte caching to handle traffic for all applications. Since byte caching works at the TCP layer, its deployment does not require any changes to the applications themselves or application configuration. This satisfies the requirement that it should be transparent to applications and users. In the Blue Coat WAN Optimization solution, the policy engine provides the capability to associate the data with specific applications and users providing control over what data gets cached and what gets blocked. <br />
<br />
While byte caching accelerates all TCP traffic, some of the specific application protocols that can be accelerated using byte caching are –<br />
<br />
<ul><li style="">Web – HTTP, HTTPS (SSL)</li><li style="">Streaming media – Video on demand</li><li style="">Email – MAPI, POP and any other email protocols</li><li style="">File services – CIFS, NFS, Data Storage Management solutions and any other file services</li></ul><br />
<br />
Byte caching is designed to work in a mesh, hierarchical or any arbitrary network design and<br />
imposes no limitations on the design of corporate networks. Byte caching works well with all of the other WAN Optimization technologies: object caching, bandwidth management, protocol optimization,<br />
and compression.<br />
<br />
<b>Object and byte caching together decongest the WAN and reduce latency </b><br />
<br />
Object and byte caching, when applied to enterprise WAN traffic, result in acceleration of enterprise applications and reduction of WAN bandwidth requirements. Together, these technologies cover a wide set of applications and form the backbone of a solution for WAN challenges that enterprises face with the consolidation of their branch office server infrastructure. In addition to providing coverage for a wide set of applications, synergy between the two approaches to caching makes the overall system better than the sum of its parts e.g. existence of byte caching results in transfer of fewer bytes if the object gets changed/modified at the source. This property helps object caching subsystem to be aggressive on adaptive refresh algorithms for keeping the content fresh in the local cache and thus improving the response latency in the branch office. Similarly, existence of fresh content in the object cache results in fewer TCP round trips by the byte caching subsystem since the request can be served locally.</blockquote>

]]></content:encoded>
			<dc:creator>TimC</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?5-Byte-Caching</guid>
		</item>
		<item>
			<title>Caching and Compression – Key Complementary Technologies for Application Acceleration</title>
			<link>http://adsm.org/forum/entry.php?4-Caching-and-Compression-–-Key-Complementary-Technologies-for-Application-Acceleration</link>
			<pubDate>Thu, 30 Apr 2009 20:15:41 GMT</pubDate>
			<description>Caching and compression are two complimentary technologies that combine to minimize the amount of data that traverses the WAN, in a WAN Optimization...</description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore">Caching and compression are two complimentary technologies that combine to minimize the amount of data that traverses the WAN, in a WAN Optimization solution.  Working together, caching minimizes the transmission of duplicate data over the WAN while compression reduces the total amount of data to be transmitted. <br />
<br />
Caching and compression are two of the five technologies that Blue Coat uses to deliver its application acceleration framework.  In this blog post we'll discuss two approaches to caching, object caching and byte caching, that combine to deliver both caching and compression. (Byte caching is technically “caching,” but it is commonly considered compression. For this post it will be referred to as a caching technology.) <br />
<br />
Caching technologies improve response times and WAN utilization by keeping copies of data locally at the remote office locations and serving data locally when a request for the data is seen. <br />
<br />
First we'll look at object caching, which has been around for several years and was used mainly to accelerate access to web content. This paradigm has been expanded to include other kinds of content (e.g. CIFSaccessed<br />
files, FTP-accessed files, HTTPS, video or streaming media objects, and data storage management solutions like Tivoli Storage Management). Occasionally, object caching is referred to as “proxy caching” since it is implemented using a proxy for the given protocol (e.g. HTTP, HTTPS, FTP, CIFS, or RTSP/RTP).<br />
<br />
<b>How object caching works</b><br />
<br />
The mechanism of object caching is simple. The client sends the request for an object (file,<br />
document, image etc.) to the server; this request is intercepted by the proxy that is pretending to be the server itself. Upon receiving the request, the proxy checks to see if it has a fresh copy of the object requested in its cache. If a copy is available, the proxy responds by sending the cached object to the client, else it relays the request to the server. The response from the server is cached by the proxy for responding to future requests from clients. Although the mechanism of the proxy is simple, it poses several challenges to the implementers – most significantly, content freshness and storage.<br />
<br />
<b>Content Freshness</b><br />
<br />
The copies of the cached object have to be kept fresh, or serious data integrity issues ensue. Because content on servers changes, an object cache must keep its temporary store of content up to date. Traditionally, for a proxy to deliver content to the end user with the confidence that the data is fresh, it must send a &quot;refresh check&quot; to the origin server. However, to serve the content quickly, it must not wait until a user requests the content before it performs this refreshing activity. If the refresh checks are performed only at the moment the user requests the content, the user will endure the round-trip delays that cause the Internet to be slow in the first place and application response time will not be substantially improved. Blue Coat’s object caching technology uses intelligent adaptive refresh algorithms to guarantee freshness of the content – without negatively impacting the network with unnecessary refresh checks.<br />
<br />
<b>Storage</b><br />
<br />
Another challenge is storage, since storing millions of application objects on a general purpose file system may not be efficient and may result in added latency due to disk reads. The method of storing objects on disk is critical for achieving both high performance and high scalability. It determines (1) how quickly a cached object can be accessed when a client requests it, (2) how rapidly new objects can be acquired and stored on disk, and (3) the rate at which client requests can be serviced per disk drive. The Blue Coat’s SGOS object storage system is not a file system. It is an object cache. There is no directory in the OS. Object access is through a hash table in RAM, ensuring that any object can be obtained in a single disk read. File systems run poorly when they are full, while a cache achieves its highest performance when it is full. Blue Coat’s proxy appliance normally runs with its disks full of objects. Old, seldom-used objects are continually removed to make room for new incoming objects. The disk layout and replacement algorithms in the OS facilitate this process to optimize the speed of writing new objects to disk.<br />
<br />
<b>What is it good for?</b><br />
<br />
Object caching is a perfect technology for the following applications<br />
• Content does not change very often such as images, logos and some documents.<br />
• Content can be pre-populated on the remote devices before any user tries to access it e.g. ELearning,<br />
multimedia applications.<br />
• Several users need access to same files and the files do not change often.<br />
When object caching is appropriate, it results in zero WAN roundtrips for the content that is<br />
cached locally. In this scenario, users experience vast improvements in application<br />
performance, and WAN link is utilized much better as compared to other technologies. However,<br />
dynamic content generated by applications may not see any performance improvement. If the<br />
two objects differ by only one byte, the whole object still needs to be downloaded over the<br />
WAN link.<br />
<br />
In our next blog post we'll look at Byte Caching.</blockquote>

]]></content:encoded>
			<dc:creator>TimC</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?4-Caching-and-Compression-–-Key-Complementary-Technologies-for-Application-Acceleration</guid>
		</item>
		<item>
			<title>WAN Optimization and Tivoli Storage Management</title>
			<link>http://adsm.org/forum/entry.php?3-WAN-Optimization-and-Tivoli-Storage-Management</link>
			<pubDate>Wed, 25 Mar 2009 19:05:16 GMT</pubDate>
			<description>WAN Optimization can be used to accelerate and optimize IBM Tivoli Storage Manager across Wide Area links, solving problems many storage management...</description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore">WAN Optimization can be used to accelerate and optimize IBM Tivoli Storage Manager across Wide Area links, solving problems many storage management administrators face.<br />
<br />
Today, organizations face an expanding set of data protection and retention challenges. IBM Tivoli Storage Manager is a popular solution for centralized, automated data protection that reduces complexity, manages costs and aides compliance. To accomplish these goals, IBM Tivoli Storage Manager must replicate large amounts of data across the wide area network. WAN links, however, have higher latency and much less bandwidth than either a LAN or Fibre Channel network. Latency severely impacts the performance of protocols that TSM relies on for WAN communication, and the amount of data often dwarfs the bandwidth most organizations can afford. Even using TSM’s intelligent data move-and-store techniques, the amount of data can still be significant, and much larger than can be moved across the WAN during the backup window. If differential backups take hours, and a full restoration takes days or longer, how can organizations effectively maintain backups? Or worse, how can they expect to restore them quickly in a real disaster?<br />
<br />
Blue Coat Systems is one WAN Optimization vendor that offers a set of technologies including byte caching, compression, protocol optimization and bandwidth management, significantly improve IBM Tivoli Storage Manager data transfers.  In this blog we'll examine each of these technologies in more depth in coming posts to this blog.<br />
<br />
Tivoli Storage Manager has many data transfers that can be optimized with WAN Optimization technology. Backup Set initialization triggers a massive amount of network traffic which is highly repetitive and very compressible. Progressive and Incremental updates also contain much repetition; although the data is new in each individual file (or sub-file backup), the byte patterns between files are very redundant and respond well to compression and caching. This allows WAN Optimization technologies to improve initialization, recovery, and update times by up to 90% in real customer deployments.<br />
<br />
Some WAN Optimization solutions go beyond just compression and protocol optimization, by providing bandwidth management to control access to network resources.  Bandwidth management can prioritize traffic based on user, application, time of day and content, ensuring that IBM Tivoli Storage Manager gets the bandwidth it needs both during the backup window, and in the event of an emergency restore.<br />
<br />
Examples of WAN Optimization successes include tests conducted in labs and within customers’ live environments show that Blue Coat appliances significantly improve the performance of IBM Tivoli Storage Manager in real world scenarios. At one customer, using Blue Coat WAN Optimization technology, the time needed to complete a backup operation was reduced by over 508% on the first (cold) pass, and subsequent backups by almost 90%. Bandwidth used to complete the backup or restore was also reduced by over 60%. Such a dramatic improvement makes it possible for our customers to complete their backups within the nightly window again. For a new full Backup Set initializationrestoration, Blue Coat reduced the overall time to clone by over 3041 times; convenient for IT when creating sets, but that performance increase would be critical in the event of an actual restore due to data loss or disaster.</blockquote>

]]></content:encoded>
			<dc:creator>TimC</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?3-WAN-Optimization-and-Tivoli-Storage-Management</guid>
		</item>
		<item>
			<title>WAN Optimization Overview</title>
			<link>http://adsm.org/forum/entry.php?2-WAN-Optimization-Overview</link>
			<pubDate>Tue, 24 Mar 2009 01:28:01 GMT</pubDate>
			<description>Wide Area Networks (WANs) have a notoriously bad reputation for throughput, uptime, and reliability. High latency in WAN links break applications and...</description>
			<content:encoded><![CDATA[<blockquote class="blogcontent restore">Wide Area Networks (WANs) have a notoriously bad reputation for throughput, uptime, and reliability. High latency in WAN links break applications and an over-consumption of bandwidth creates bottlenecks. For a variety of reasons, performance of applications over the enterprise WAN is poor and getting worse. Sometimes, the problem is created by server consolidation; servers and users moving further apart, introducing latency and ever-greater bandwidth demands. Other times, it's a new application deployment that either wasn't tested in remote offices or simply pushes the bandwidth beyond what's available - but in either case making it unusable outside headquarters. Whether the problem first appears as a backup problem, file copy problem or just a couple of applications that don't perform the way they should, there is an acute and growing perception that there is something wrong with certain business critical applications.<br />
 <br />
 <br />
LAN and WAN applications communicate differently by design, and one size doesn't fit all.<br />
Applications designed for the WAN feel stodgy, cumbersome and user un-friendly, such as FTP<br />
and telnet. LAN applications, on the other hand, are usually very simple, user friendly and quite<br />
responsive; it's easier to drag and drop a file than open an FTP session, for example.<br />
Unfortunately, however, LAN applications simply don't work on a WAN. In the past, insufficient bandwidth was often blamed for poor WAN performance. This was partially true; historically, bandwidth prices were higher and overcrowding led to waits and queuing. But even if you add more bandwidth, many networks are running into a more fundamental limitation, namely latency. Latency ruins many LAN applications - they simply weren't designed to deal with it. Even for technologies tolerant of latency, there is no way to escape waiting for packets to arrive. To improve performance, something must be done not only to reduce bandwidth and prevent future overcrowding, but handle the effects of latency.<br />
 <br />
WAN Optimization was developed as a way to bring a LAN-like experience to the WAN. At first, there were point solutions that either pixel-scraped screens or just throttled bandwidth. However, the industry has more or less stabilized around a few, rapidly commoditizing technologies to address WAN performance problems. The first is to fix LAN protocols that break over the WAN by changing their behavior. Commonly, CIFS file services, MAPI email and the underlying TCP protocols are<br />
enhanced for high-latency environments. Another technique is to use various types of compression (and caching) to reduce bandwidth. Most effective is Byte Caching, a technique that removes redundant data directly from the bit stream by caching common patterns. It's very effective at reducing bandwidth, although it has little or no effect on overall latency.<br />
 <br />
Finally, since many WAN Optimizations are file service specific, they sometimes create a redundant<br />
overlay network of file servers to bring files closer to the end user. These &quot;file server lite&quot; appliances<br />
simulate a local Windows server at the remote office, effectively undoing server consolidation.<br />
These technologies help, but they only address part of the problem - what about the rest of the<br />
traffic? If you look inside your WAN networks today, most are not just filled with CIFS and MAPI<br />
traffic. They are teeming with a variety of applications, protocols and content. Some of them<br />
shouldn't be there and are just wasting space, but many are business critical and need to be<br />
optimized. The last part of WAN Optimization is controlling this traffic.<br />
 <br />
Despite years of talk, and some action, there is still a surprising amount of unnecessary or<br />
outright unseemly traffic on corporate WANs. Even for organizations that aren't concerned with<br />
the productivity loss of extraneous web surfing and downloads, rapid increases in both web<br />
traffic and multimedia content threaten to crowd out business applications.<br />
Legacy WAN Optimizations solutions either don't affect the junk, or attempt to minimize the<br />
problem by accelerating it along with the good traffic. Like upgrading bandwidth, however, this<br />
does nothing to slow or stop the use of these services - in fact, by making them work better in<br />
the short term, they actually encourage further use of bandwidth-intensive external services.</blockquote>

]]></content:encoded>
			<dc:creator>TimC</dc:creator>
			<guid isPermaLink="true">http://adsm.org/forum/entry.php?2-WAN-Optimization-Overview</guid>
		</item>
	</channel>
</rss>
