Share This [+]
March 17th, 2010 by Jeff P.
Trying to go viral? Planning on a lot of site traffic? Our techs have helped sites stay online during Super Bowl ad campaigns and opening weekend movie premiers. And along the way, they’ve learned what it takes to stay online during a massive flood of traffic.
So before going live with the next greatest Internet meme, here’s a checklist of what to do to keep your site alive:
- Understand the scope of the project. How many people will be exposed to your campaign? What is the expected turnover rate? What time of day do you expect traffic to hit your site? How will your site’s application handle a dramatic increase in visitors?
- Allocate enough time for planning. The right amount of prep time depends on the scope of the project. Is one week really enough time to bring everything together? One month? The bigger the project, the more time you will want in advance to make sure everything goes smoothly.
- Be prepared for all the what-ifs. Expect the unexpected; people, especially visitors to your site, never behave exactly the way you expect them to. Map out all of the scenarios and have a plan ready for them.
- Have a back-up and back-out plan. As much as you prepare for success, never assume that failure is impossible. Failing gracefully can make a big impact on retaining the trust of your visitors. Also, you don’t want to lose valuable data. If your site crashes under the load, make sure you can retrieve the data gathered before the crash.
- Make sure your configuration is scalable. Being able to add an additional web server without downtime means that you won’t interrupt the traffic surge in order to accommodate an unexpected volume of visitors. If your site relies on a database or dedicated application server, make sure you can add more power to these areas, as well.
Read the full post »
Tags: marketing campaign, uptime, viral, web performance
Share This [+]
March 10th, 2010 by Chris G.
It might seem obvious, but those with less data have arguably simpler storage requirements. Perhaps not so obvious is how many different areas can be impacted as data grows. Backup storage, backup duration, restoration, inter server network connectivity, DR plans, system disk I/O performance, and (of course) your primary storage. More often than not, a review of one’s data reveals things that can be archived or deleted. Some examples:
- E-commerce sites might look to save space by archiving older orders or discontinued products.
- Data reporting/analysis systems might be able to archive or delete the raw data that the reports or analysis are built from.
- Those affected by regulatory compliance should understand their requirements for keeping logs or other items “online” versus “available”. In many cases, only the most recent items need to be kept online. Older items can be archived.
Case study
A popular number crunching website used to try and keep everything online. This caused their database to grow until performance suffered and backups became unwieldy. Their database alone topped out at 300GB! INetU was asked to assist with tuning their database and scaling their backups. INetU found that over 75% of the data within the database was not regularly accessed – especially older than 3 months.
Read the full post »
Tags: data management, storage
Share This [+]
March 3rd, 2010 by Andrew H.
With all of the talk about virtualization lately, many organizations are ready to pick up everything and virtualize it. After all, it’s the thing to do! Here are some things to keep in mind before virtualizing everything in sight:
1. Don’t virtualize highly utilized servers
One of the biggest benefits of virtualization is being able to make better use of your hardware. Adding virtualization doesn’t add more horsepower to your server; in fact, it’s another layer that can reduce performance. If you have a service that is already using most of the resources on a fairly powerful server, there’s a good chance that it might not be the best candidate for virtualization. If you decide to virtualize a workload that is disk intensive, consider using a raw pass through disk instead of a virtual hard disk to improve disk I/O performance.
2. Don’t cluster a cluster
Many virtualization platforms allow you to provide for some level of high availability for your VMs. Applications can provide a similar feature, but use caution when using them together. Generally speaking, services clustered with Microsoft Cluster Services that use a shared disk should never be configured in a way that makes the virtual machines automatically move from one server to another. Having multiple levels of failover might cause unexpected results and unnecessary disruptions to users.
3. Don’t virtualize everyone’s desktop (and expect to save money)
There are some legitimate benefits to virtualizing desktops, but cost is usually not one of them. No matter where a desktop is, users still need something to access it with. Server hardware is also inherently more expensive than traditional desktop hardware. On the other hand, virtualized desktops can be a great fit for remote employees, as backup workstations, or to ensure standardized desktops. In most cases, however, a Remote Desktop Services session host (previously Terminal Services and available only on Windows machines) can provide a cheaper and more efficient alternative provided that users don’t require administrative privileges.
4. Don’t create conflicting dependencies
Read the full post »
Tags: virtualization
Share This [+]
February 25th, 2010 by Jason B.
As companies are looking to cut costs, many ponder moving their infrastructure to a managed hosting environment rather than maintaining it themselves. Saving money is always an appealing option to any CEO, but the first questions always raised are, “How will our infrastructure respond if it is a hundred of miles away? Will our file sharing performance be hurt due it not being on the local LAN?”
These are all very good concerns and, in some cases, can be deal breakers for the company. But, there is help out there, and the solution is proven and being praised by many. That solution is Cisco WAAS.
Cisco WAAS, or Wide Area Application Services, allows you to centralize applications and storage in a managed host, while still maintaining LAN-like performance. And that is just the start of things!
WAAS allows you to:
- Save money by not having to have dedicated floor space locally for a data center.
- Not have data across many servers in many locations that is different everywhere.
- More efficiently use WAN connections, and prevent unnecessary upgrades to those circuits.
- Have the uptime and reliability for their servers that come with a Managed host, and not have to worry about issues like failures, MRO stock, support contracts etc.
Implementing WAAS is pretty straightforward. Depending on your exact needs, there are different models and implementation details, from a local module on an ISR router, to a full-fledged dedicated device. Here is how Cisco WAAS works the magic:
Read the full post »
Tags: cisco, lan, waas
Share This [+]
February 17th, 2010 by Jason C.
Many people hold a misconception that Peer-To-Peer replication and active-active clusters can provide write scalability. This article will provide a very brief overview of both technologies and some details as to why these technologies are not capable of scaling write operations.
Peer-To-Peer replication will provide you with the ability to read and write from multiple nodes, which in turn provides read layer scalability and read/write high availability. Although read operations scale very well, write operations are not improved and the write performance would be similar to that of a single node. This is true because all inserts, updates, and deletes are written to all nodes in near real time.
An active-active SQL cluster is a term that is a little misleading as this technically doesn’t exist in SQL Server. It is really a multiple instance cluster since a SQL cluster can only have one instance running on one node at a time. To make the other node perform database operations, you would need another instance running on that node and manage them in such a way that they are always running on a different node from one another. As this scenario does not allow you to run a single database across more than one node, this technology will also fail to provide you with scalability of your database write operations.
There is no out-of-the-box functionality that will provide write scalability in SQL Server, but there are manual processes that can be undertaken to accomplish this goal. For example, you may have heard or seen the word sharding before during your quest for the holy grail of write scalability. Sharding is the technique of splitting up a database into smaller databases. Sharding the database is really the only way to provide scalability of write operations in your Microsoft SQL Server environment.
Ultimately, the limitation of how scalable you want your write operations to be depends on how much work you’re willing to put into splitting up your database and modifying your application so they can deal with the interaction between the multiple databases.
What has worked for you? Let us know!
Tags: clusters, Scaling, sharding, SQL, SQL Server, Writing
![[]](/imagesb/reflection02.gif)