15 Feb, 2009

Pros and Cons of Diskless Servers booting off a SAN

Posted by Bhavin Turakhia | (3) Comments

In our constant efforts towards Architecture nirvana we are often faced with the question of whether a cluster of application servers should have their own hard disks or should they PxE boot off a SAN. This short article explores the options

Notes

• If a cluster of machines have their own OS hard drives, and one cannot afford a machine going down then each of the machines would need a RAID 1 config which requires a RAID card and 2 hard drives each resulting in a considerable cost (high-cost)
• In the scenario where multiple machines boot off a partition on a SAN device, the machines do not need any harddrives. However if for any reason the connectivity to the SAN goes down or the SAN device itself crashes (rare) then all the machines in the cluster would be down (marginal redundancy concern)

Conclusion

• In the scenario where the data partition of the cluster of machines is residing on a SAN device, it makes sense to boot those machines off the SAN device too since as such the SAN going down would render the entire cluster useless, and this way one can save the cost of 2x’n’ hard drives and ‘n’ RAID cards (assuming we have ‘n’ machines in the cluster)
• In the scenario that a cluster of machines does not have any data on a SAN device, one may want to invest in hard drives for the machine itself, since a downtime of the SAN device will not render the cluster inoperational. Additionally, if the cluster consists of 10-15 machines, the cost of 2 SATA drives and 1 RAID card per machine may not be much higher than the cost of a SAN device if one needs to be exclusively setup for these machines.
• This may change however if one has spare and redundant SAN devices lying around, with spare capacity in their network
• Ideally if a cluster of machines are to PXE boot off a SAN, one should try and ensure that the boot partitions are spread across separate SAN Devices each of which are accessible through different network paths, so that the downtime of any given SAN Device does not compromise the cluster

15 Feb, 2009

Notes on Amazon EC2

Posted by Bhavin Turakhia | (4) Comments

Sandeep Shetty from our Products team introduced me to Scalr – an opensource self-scaling hosting platform based on the Amazon EC2 cloud. I decided to take a quick look under the hood and figure out how Amazon EC2 would function as a hosting platform. Here are my quick notes -

Intro

• EC2 offers the ability to instantly provision Virtual machines using an image (called AMIs) through an API
• Each instance is like a VPS with a certain amount of RAM, CPU, Disk capacity
• CPU capacity of an instance is measured in the form of EC2 Compute Units. From their FAQ – each EC2 Compute Unit provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor

Pricing

• There are various types of instances
• As an eg, an instance with 4 EC2 Compute Units, 7.5 GB RAM and 850 GB storage would cost 40 cents per hour => ~$300 per month
• Data Transfer costs 10 cents per GB for outbound transfers and between 10-17 cents per GB for inbound. Assuming only outbound data transfer (typical case for a web app) and the lowest rate on EC2 (10 cents per GB) the cost per Mbps per month for EC2 works out to be approximately $32.
• For any persistent storage over and above that provided in the instance one can use Amazon Elastic Block Storage or Amazon S3.
• Amazon EBS costs are 10 cents per GB per month + 10 cents per million I/O requests

Notes

• Many people tend to wrongly assume that EC2 (which stands for Elastic Compute Cloud) allows you to provision resources in an elastic manner and scale your application ad infinitum without any changes to the application. While in theory you can provision instances dynamically upon need, each EC2 instance acts like an independent machine with an independent OS, memory, CPU etc. It is identical therefore to provisioning multiple hardware boxes and any partitioning / load balancing etc would need to be done by the application developer at the App layer
• The elasticity does have considerable advantages in as much as provisioning is fully automated and each instance can be added / removed at a moment’s notice (about 10 minutes to boot up a new instance according to their FAQ) thus taking care of peaks dynamically
• Additionally no hardware setup is required to add / remove an instance
• Instances are provisioned through images which take care of complete setup thus relieving any system administration effort in setting up a machine
• Amazon EC2 provides the ability to place instances in multiple locations. Amazon offers multiple regions (USA / Europe) and various Availability Zones within these regions. Availability Zones are distinct locations that are engineered to be insulated from failures in other Availability Zones and provide inexpensive, low latency network connectivity to other Availability Zones in the same Region. Using instances in separate Availability Zones, one can protect applications from failure of a single location.
• Setting up an EC2 instance is quite easy. Once you create your AWS account, you can use the online AWS Console or simply download the offline command line tools to start provisioning your instances. Check the AWS Console Video for more details on the AWS Console.

Applications

• I can think of using EC2 instances for DNS infrastructure. Easy to deploy, and can scale dynamically to manage high loads. Additionally DNS servers do not require lots of storage and are innately redundant by virtue of the DNS protocol. Lastly, since EC2 provides multiple regions and zones, the DNS infrastructure can be scaled out resulting in geographical redundancy
• EC2 is great for prototyping as well as benchmarking
• One can also use EC2 deploying small web apps reducing time to market and allowing quick setup
• Many applications have monthly report generation requirements which too can be run of an EC2 instance. EC2 offers SQL Server instances incase you want a commercial database to run reports / crunch data.
• We have also been thinking of using EC2 for CodeChef. Since at CodeChef we plan on running a programming contest each mont, visitors as well as computing resources required to manage submissions increase considerably around the time each contest is announced. This makes Amazon EC2 a perfect candidate for dynamic resource deployment during contest-week

Other Amazon Web Services

• Amazon S3 provides a scalable, high-available and redundant NAS that can be used to store and retrieve any amount of data
• Amazon CloudFront is their CDN layered onm top of S3. It delivers content using a global network of edge locations. Requests for objects are automatically routed to the nearest edge location

Resources

• http://www.scribd.com/doc/2569362/Exploring-Amazon-EC2-for-Scaleout-Applications
• http://aws.amazon.com/ec2/
• http://aws.amazon.com/ec2/faqs

4 Feb, 2009

Introduction of New TLDs will NOT increase costs for Trademark Holders

Posted by Bhavin Turakhia | (4) Comments

As an ICANN accredited Registrar, a consultant to Registrars and Registries, and an erstwhile chair of the Registrars Constituency, I am very closely involved with the ICANN bottoms up consensus processes. Amongst the most interesting endeavors of ICANN, and a fundamental element of ICANN’s goal is the creation of new gTLDs. Some of the recent comments on the new gTLD applicant guidebook seem to suggest that creation of new gTLDs will result in a cost increase to existing trademark holders who will have to register their trademark in various TLDs as a defensive mechanism.

Paul Stahura published a great report demonstrating that trademark holders have historically not been blocking their names across multiple Top-Level Domains (TLDs). I have always been a fan of number crunching—”numbers never lie”.

Since Paul has already done a remarkable job of statistical analysis, I am going to wear my theorist hat and prove a reworded form of the Hypothesis using logical deduction and common sense.

Hypothesis – Introduction of new TLDs will not increase the sum total registration cost that trademark holders need to spend on domain names.

Methodology – Logical deduction.

Fact:
There are currently over 280 TLDs of which a little over 250 are ccTLDs in the IANA root zone.

Assumptions:
Individuals and companies spend money for economic gain. Therefore whether a registrant is an organization, a speculator, a cyber squatter, or a phisher, their purpose in registering a domain name is to derive economic gain that outweighs the cost of the domain name.

Description:
Let us start by analyzing why one would want to register a domain name in each additional TLD outside of the primary TLD that they use for their business. Lets take the example of a company—Extra Cautious Inc.—who uses the domain name extracautious.com. They now need to evaluate whether it makes sense for them to register the string extracautious in other TLDs. Here is the reasoning that the CFO of Extra Cautious Inc. would go through.

Traffic expectation:
It makes sense for the CFO to register extracautious.biz or extracautious.info in case an adequate number of people are expected to type in extracautious.biz in their browser directly. The number of type-ins needed to make it worthwhile to register this domain name is negligible given that .biz and .info domains cost substantially under $10 per year. If there is a clear traffic value to be derived, then as Paul has pointed out in his elaborate report, the registration of this additional domain name is not a cost but rather a revenue generation opportunity for Extra Cautious Inc, who otherwise would have missed out on the hits. Therefore in case of a Traffic Expectancy the hypothesis above holds true.

Source of traffic:
A typical website gets traffic in two ways. Either through direct type-ins, or via hyperlinks. Both the former and the latter are primarily a function of the domain name that an organization promotes. When Extra Cautious Inc. promotes extracautious.com as its website on its stationery, advertising etc., it expects people to type in that domain name to reach their website. It also expects search engines to index that domain name, and other directories and websites to link to that domain name. In other words traffic through type-ins and hyperlinks would directly end up on their website.

Next let’s explore the possibility of direct type-in traffic on other TLDs. Users on the Internet type-in a domain name directly if they expect to find the website or information they were looking for. The most common case of this is appending a .com to a company/product name. It is common behavior on the Internet to append a “.com” to the end of a company name to look for its website. In some cases people even append a .net or a .org. However, given Google magic, that is the limit of a user’s patience. One does not have to be Einstein to conclude that no users are trying out 280+ TLD combinations to get to a company’s website. It can therefore be assumed that if 50 new TLDs, each quite different sounding from the other, were to be launched, that users on the internet would not begin to iterate through those 50 TLDs to find a company.

ccTLDs type-ins:
In fact the only other type of domain that tends to get type-in traffic is ccTLD equivalents. This is based on two behavior patterns. Users seeking for a company that they know is based in India, could try to reach that company’s website by appending “.in” to the company name as a last resort after attempting a .com / .net / .org search. Similarly, users from India, who are used to seeing “.in” domains may append “.in” to a company name (e.g. dell.in) to find its local website. By this logic, many companies should ideally have registered their domain names in several ccTLDs, especially those of highly populated countries like India and China. Yet the TLD Zones of these ccTLDs have little overlap with the global trademark registry as well as with the .com zone, barring generics and some fortune 500 companies.

Many new TLDs have a specific purpose:
Add to this the fact that many of the proposed new TLDs have varying creative purposes. We have heard of business models such as .wiki, .blog etc. which have such specific purposes. Type-in traffic on those TLDs for a specific trademark such as Extra Cautious Inc, is highly unlikely, since users would not expect Extra Cautious’ website to be available at extracautious.wiki.

No traffic expectation:
Going back to our first point—in case no one is expected to type in extracautious.newTLD, it makes little sense for Extra Cautious Inc. themselves to register extracautious.newTLD. This for instance applies to specific TLDs like .aero. Since extracautious is in the business of making fireworks … they do not expect any of their existing or potential customers to type in extracautious.aero. Similarly since Extra Cautious Inc. largely operates in the US, it may block extracautious.us but chooses not to block extracautious.in. The likelihood of individuals typing in extracautious.biz and extracautious.info ad-hoc is ZERO so they do not need to block those domains. If there is a traffic expectancy on any TLD option, it is a no brainer to block those domains since the potential revenue would outweigh the cost.

What about cybersquatters:
The next argument typically made by IP constituencies is that if a speculator / cybersquatter / phisher were to register extracautious.newTLD then they could create nuisance value and the company may be prompted to block their domain name (defensive registrations) to prevent this nuisance value.

It is important to understand that CyberSquatters / Speculators / Phishers register non-generic trademark domain names for specific economic reasons. Let’s explore these.

Type-in traffic on trademark names:
If a trademarked domain gets type-in traffic, a speculator maybe prompted to register this domain to monetize the traffic. However in this case, as we have discussed before, a trademark holder themselves would wish to register it prior to a speculator since the revenue outweighs the cost. If a speculator can earn more than the cost of the domain name by simply monetizing traffic to that domain name, then it is assumed that the actual trademark holder can earn significantly higher revenue and therefore is not bearing any cost by registering his domain name in that TLD. Therefore Extra Cautious Inc. chooses to register extracautious.au since it has an office in Australia and expects type-in traffic from Australia. This is not an extra cost for them since through this additional domain they get traffic that they would have otherwise not received.

Defensive registrations to prevent misrepresentation or blackmail:
Some folks argue that even if a domain name has no traffic potential, speculators can choose to register the same to either fraudulently pretend to be the trademark holder (phishing etc.) or otherwise to try and sell the domain name to the trademark holder for a premium. Let’s analyze both these arguments.

Mr Scrupulous registers extracautious.info and puts up a website on it to sell fireworks. He intends to spam thousands of users, pretending to be Extra Cautious Inc. and leverage on the advertising campaign of Extra Cautious Inc. to earn money. It can be argued that if Extra Cautious Inc. had registered their .info domain name this could have been prevented. However this argument is flawed, since Mr. Scrupulous could have registered extracautiousweb.com, extracautiousonline.com, extracautiousfireworks.com, extracautiouscrackers.com, extracautiousoffers.com, extracautiousshop.com and a gazillion other variants within the .com space itself. By this logic the CFO of Extra Cautious Inc. would need to register every combination of extracautious in the .com and .net and .org TLD spaces. Therefore new TLDs are no more expensive than existing TLDs when it comes to protecting one’s trademark from identity theft/phishing. In fact I would go so far as to submit that phishers and spammers would rather register <company&rt;online.com or <company&rt;web.com or some such variant in the .com TLD space in order to commit identity theft, than to register a .info / .biz domain name, since .com domain names are easier to relate to for users. While I have conducted no statistical analysis, gut feeling tells me that one will find more variants of Fortune 500 company brand names in the .com TLD than defensive registrations of those trademarks in all other TLDs.

Let’s take a look at the second argument, wherein Mr. Scrupulous registers extracautious.info with the sole purpose of reselling it to Extra Cautious Inc. for a profit. This has already been covered in our previous assertion. The CFO of Extra Cautious Inc. would only buy extracautious.info at a certain price if the expected profit from the purchase was higher, in which case the purchase does not result in a cost increase. Additionally, Extra Cautious always has the option of filing a dispute, instead of purchasing the domain from Mr. Scrupulous, and this knowledge is by itself sufficient to prevent widespread blackmail of this form. If extracautious.info is getting no traffic, then Extra Cautious Inc. has no reason to purchase extracautious.info either directly or from Mr. Scrupulous

Conclusions:

• Trademark holders have no reason to register a domain name in a newTLD if the domain name is not going to get any traffic
• Speculators have no reason to register a domain name in a newTLD if the domain name is not going to get any traffic, since they will be unable to generate revenue from it or sell it to the trademark holder
• Spammers and phishers have adequate options for registering similar sounding domain names in existing TLDs without having to bother with new TLDs
• Thus, it can be concluded that the Introduction of new TLDs is not increasing the sum total registration cost that trademark holders need to spend on domain names