Sales
Support There has been a lot in the press recently about the problems (particularly) Riverbed has been having with the new AutoCAD file formats for 2007 and 2008 http://esgblogs.typepad.com/brians_blog ... ns-co.html is an example of what’s out there.
The problem manifests itself when you save files, where the new file format means there is negligible acceleration achieved (Riverbed quote 1.3x) and users make references to bricks. Riverbed claim 7.64x improvement with AutoCAD 2004 using the old file format.
Packeteer have been doing some work to look at the performance of their iShared and iShaper WAFS system and say the remote user will see no difference with their system whichever file format they use.
“With Packeteer’s iShaper and iShared solution the transition from earlier versions of AutoCAD to AutoCAD 2008 was seamless and trouble-free,” said Vaughn Silar, president & CEO of Paragon Engineering Services, Inc. “In optimizing our AutoCAD 2008 files across the WAN between multiple offices, Packeteer was able to deliver the same high performance application visibility, acceleration and intelligent service assurance for which we have come to depend on them.”
In tests using 80ms round trip latency over T1 lines, Packeteer found that an 8MB AutoCAD 2008 file took 140 seconds to save across the native WAN while that same file took only seven seconds to save with the iShaper solution, a performance improvement of 20x. Packeteer’s iShaper solution performance was also not affected by ISP (Increment Save Percentage) changes that Autodesk 2008 utilises to optimise the size of the AutoCAD files upon file saves and which negatively impact the performance of other WAN Optimisation solutions.
These results can be attributed to Packeteer’s CIFS acceleration which employs a superior WAFS architecture that ensures local file server-like performance and is future-proofed against any protocol or file format changes for CIFS applications. With a combination of streaming, file object caching and byte data reduction technologies, the WAFS technology built into Packeteer’s iShared and iShaper solutions always deliver the fastest user response times on file opens and saves.
By way of confirmation of the performance of the Packeteer solution, in an April 3, 2008 review by InfoWorld Magazine’s Test Center, reviewer Keith Schultz said, “Packeteer’s iShaper is at its best optimizing CIFS traffic and shaping traffic on the WAN. Its overall optimization and acceleration is right there with the best of them; its CIFS performance is the best I’ve tested. Reporting too is top notch, and the single point of administration makes it easy to manage the appliance.”
[ add comment ] ( 6 views ) | [ 0 trackbacks ] | permalink
InMage have released the latest version of their DR-Scout, business protection software, which provides CDP (Continuous Data Protection), replication and automated application failover.
A host of new features and configuration options are included in the new release, with application support now including:
- BlackBerry Enterprise Server (BES)
- Oracle
- SAP
- SharePoint
- Exchange
- SQL
- Virtual Servers
- VMware
- Virtual Server
- Oracle VM
...Read more - Product Information
[ add comment ] ( 10 views ) | [ 0 trackbacks ] | permalink
As people get in to real life uses of Mazu Profiler you can see the lights starting to turn on.
It’s interesting because it is one of those products where people always say “we have something which will do that”. Then they see it running and the realisation dawns.
A simple example came up today at a customer. The CEO had had a laptop a remote office where he was due to do a presentation to some new starters. Users at the remote site started complaining about poor performance of the network. Looking at the Mazu dashboard it was clear that the laptop was set to synchronise and was pulling 1.5GB of private files across the WAN.
Historically they would have used a sniffer or similar network analysis tool to look at this kind of problem, the difficulty with that approach is that the activity has often completed by the time the sniffer is in place, coupled with the difficulty some people have driving the snaiffer and understanding what it is telling you in the first place.
Having realised this was happening here they wondered if it was happening elsewhere and found similar instances, including one where someone had synchronised 4GB across a 2Mbps link.
Being able to look back and see what happened last minute, 30 minutes ago, 15 hours ago, 3 weeks ago, 4 months ago, is just so powerful. What is different, what has changed, does this happen elsewhere, all these are very simple to answer with Mazu.
Happily the customer was as impressed as we are.
Mazu product data...
[ add comment ] ( 5 views ) | [ 0 trackbacks ] | permalink
There has been a lot of "chatter" lately about power management, hardware failure and MTBF numbers. James , Aloof, Vinay and others have been discussing it and it's been an interesting topic to follow.
Data centres are eating more and more power, both in terms of power to the servers themselves and to the air conditioning units cooling them.
We've talked about power savings from implementing virtualisation before, here , here and here for example.
But, IT people don't like power cycling servers, partly for the reasons that James & co. have suggested. That reason being that historically the extra load put on a computer at power up has caused many a server to die. However modern computers are better engineered and the Mean Time Between Failures (MTBF) is pretty respectable.
HOWEVER....
We in IT know the fundamental law of computing... Murphy's Law.
It's not the average that gets you, it's the exception to the rule, the machine that fails or the set of machines that fail destroying the MTBF number in your data centre in a moment. It's that one server that had that one application that you didn't realise was not being backed up properly, that you didn't realise the other applications needed, that you didn't realise the CEO looked at hourly!
That server is the one that will have dual power supplies fail when you turn it off and on again, Murphy's law pretty much guarantees it.
There are two ways that Cassatt can help you deal with this.
One is balancing risk against power savings. By powering down all the servers that are not needed, you can save a large amount in utility bills. If the saving is larger than the risk of having to buy a new piece of hardware to get that one server back from the grave, then you win.
This saving can also be tracked and the saving added say to a new hardware budget instead. So you can have spare hardware ready, or better yet used to start putting the more advanced features of Cassatt into play.
Cassatt's Collage software offers the automated power control, the power savings come from there as discussed above.
Collage also allows you to automate the power, operating system and applications on a large number of hardware servers. With Collage's advanced features, you can push to bare metal an entire application server, operating system, application and even reconfigure the network switches to enable the port the hardware you have just provisioned is plugged into.
With Collage, all your servers become nodes, that all your applications could potentially run on if required.
Collage will shutdown that server we were talking about earlier at say 7pm, then try and turn it back on at say 7am (saving you all that money on power and cooling). Should the hardware fail for some reason, Collage will select a new server with appropriate CPU, RAM, DISK, etc. and push the operating system and application onto it, it'll re configure the network so that the new hardware is on the right vLAN and as far as the rest of the world is concerned it will be the exact same server as before.
So getting back to the discussion around MTBF numbers and Mr. Murphy's law. What Cassatt can do is accept that Murphy's Law is in operation, that despite advances in technology hardware will fail, that it will fail at inconvenient moments (like when you are asleep, or on holiday) and it can cope with that situation to ensure that the service levels you have configured are maintained. This is above and beyond the mission to be "green" and save energy.
So... if you believe in MTBF numbers or in Murphy's law, Collage is able to do its thing. It'll save power by shutting machines down for you and if you go whole hog, it'll handle all the rest, so you can enjoy that Martini on the beach during your holiday (or should that be Eggnog by the fireside at this time of year?).
Links:
Cassatt Page
Creating Agile Data Centre Server Environment
[ add comment ] ( 14 views ) | [ 0 trackbacks ] | permalink
In a survey of 235 organisations by Aberdeen Group, 93% of respondents said they increased their bandwidth over the last two years, but only 52% saw an improvement in application response times, only 36% saw WAN latency decrease and only 18% saw a 50% improvement in performance.
This is really no surprise. Bandwidth is rarely the problem, if only it were that easy!!
Aberdeen identifies “Best in Class” companies who exhibited common characteristics:
• Likely to have polices for prioritisation of WAN traffic.
• Centrally manage WAN optimisation appliances
• Application specific compression tools
They also identify actions to get to become “Best in Class”:
• Develop capabilities for monitoring and analysing performance of applications running on the WAN.
• Use historical data to plan chances of bandwidth capacity
• Deploy technology solutions for shaping WAN traffic
• Develop controls to limit the use of bandwidth for applications
Our view is a lot of this makes sense. Many things seem to cause confusion amongst some customers we talk to about application acceleration and WAN optimisation as there is often a lack of understanding about this pretty complicated area. We hear comments like “I can ping it OK but it runs like a dog.”
Ping is sometimes OK for testing connectivity, but that’s about it. CoS and QoS are not the same animal. Latency is a killer. Bandwidth limitations can often be overcome by other means. Even experienced network managers are often surprised when they get visibility of what is really running over their WAN. Knowing what changes (network behaviour) is key to troubleshooting as well as making sensible decisions about which applications to accelerate and which techniques to use. Once WAN optimisation and application acceleration has been applied, there is an ongoing need to monitor the WAN in detail to ensure the optimisation is doing what it is supposed to be doing.
Companies that can view bandwidth consumption per network location, and per application, per user, can better plan for changes in capacity and preserve optimal application performance. Those which can then apply policies to give granular control of those variables and measure to confirm optimal acceleration are those who are most likely to succeed with their application acceleration and provide users on remote sites with services which allow them to work effectively.
You can read the report on the Aberdeen site
[ add comment ] ( 5 views ) | [ 0 trackbacks ] | permalink
Calendar
