Signups open for beta test of Anchor’s US presence

Published November 23rd, 2011 by Barney Desmond

Good news, everyone!

Anchor’s US hosting infrastructure is ready for business. We’re not so brazen/naïve as to think that it’s perfect, but we’re pretty damned confident that it’s ready to go.

This is where you come in. Starting in the first week of December, we want to give you a free VPS for three months and see how you like it. We want you to use it, a lot, and we’re not charging for anything – not for the server, not for the bandwidth, nothing. It’s the legendary Anchor products and service, for free.

The server comes sans-management, so you’ve got root and are welcome to run whatever you like on them. If this sounds like your idea of fun, APPLY ONLINE NOW to let us know you’d like to be part of the trial.

Get in quick if you’re interested – we don’t overprovision these things, so we only have a limited number to give away. Applications are subject to acceptance of our beta agreement, and the offer is good for CentOS or Debian Linux only. Have at it!

Tags: , ,
Posted in FTW, Newsletter

 Leave a comment

0
Comments

Anchor to build a US Point of Presence

Published November 2nd, 2011 by Keiran Holloway

It’s not really any big secret that we’ve gradually been doing more and more work throughout North America. Nor should it really come as any surprise that we’ve been around doing this web hosting thing for quite a while now and are always looking at ways that we can improve our offerings to our valued customers.

On this basis, we’ve recently made the decision to commence a build-out of a US-based facility to offer an alternative point of presence based on the west coast of America.

What was the motivation behind this?

Over the past 2 years we’ve had the absolute privilege and pleasure of building and delivering various complex hosting environments in facilities other than our primary point of presence in Sydney, Australia. There obvious ones include Github, Stocktwits, GroupMe, Huggies, Leadformance and AffinityLive. We’ve had an awful lot of enjoyment building and successfully delivering custom solutions under our
remote management product. That said, however, there has been some challenges that we’ve come across and we are 100% confident that we can significantly improve our product offering by being in control of all aspects of service delivery.

Some of the problems we encountered whilst using other hosting providers included:

- Network outages during business hours whilst routing upgrades were being
completed,
- RAM upgrades and receiving RAM with errors,
- Receiving replacement drives with previous client data still resident on the
drives,
- receiving machines which had been built many months previously, left with default passwords and then subsequently compromised
- rapid deployment systems which actually don’t do either and;
- best of all, intermittent networking problems which couldn’t be solved by the network provider and we could only work around through changing the MAC addresses on the physical devices. Seriously? WHHAA?

For these reasons and various others, we’ve come to the conclusion:

This isn’t good enough for Anchor – We’re building in the US.

In this industry, reputation is everything and when you have high levels of dependence on suppliers then it can be difficult to be entirely in control of your own destiny.

Another factor in the decision making process was that, to my knowledge, there is no other managed hosting provider in the Australian marketplace which is providing, high-quality, premium style managed services using data centers in America. With up to 20% of Australian websites hosted in places other than locally, there seems to be a really unique opportunity to be providing premium support to our Australian customer-base whilst leveraging some of the benefits of having the servers physical located in the states — for example, much larger data bandwidth allocations and closer proximity to the American audience.

Over the new few weeks, we will be taking all our knowledge and skills that we’ve honed the past 10 years running a robust, reliable and premium hosting service. We’re then going to apply it to clean slate in a data centre facility on the other side of the globe.

Sound like a challenge? You betcha!

This is an very exciting time and upon completion we will be able offer high-volume bandwidth services with a US presence both to our existing to our Australian clients as well as extending our reach into the International market in the longer term. During this build up phase I am committed to providing a continous updates as to our detailed processes to give transparency into what goes into building up such an environment.

0
Comments

Why you should use LVM: part 1319755409 in an infinite series

Published October 28th, 2011 by matt

At anchor, we loves us some LVM. It makes managing storage a breeze.

Now, we’ve got one more reason to love it. Because now we have lvmsync.

Like most modern hosting companies, we run a lot of VPSes, and sometimes the chunk of storage they’re on isn’t where it needs to be, so we have to transfer it around. Ordinarily, this would involve a lengthy period of downtime while dd did it’s business and sent the whole LV across a network.

NOT ANY MORE! Now, with the magic of lvmsync we can transfer the bulk of the data while the VM is running, and then do a quick transfer of just the changes after we shut the VM down.

We think our customers will appreciate the reduction in downtime, and I know we’ll appreciate the wonders of LVM just that little bit more.

Tags: , ,
Posted in FTW

 Leave a comment

0
Comments

Awesome but often unknown Linux commands and tools

Published August 10th, 2011 by Keiran Holloway

I’ve been working in this industry for a while now and naturally spend a lot of time using Linux on a daily basis. This gives lots of exposure to various Linux commands and tools. That said, I am sometimes surprised when I see, often very experienced system administrators, using somewhat convoluted commands to do something relatively simple using a different tool.

This is my opportunity to share some of these experiences:

1. pgrep and pkill – The first command ‘pgrep’ will return the process id based on a name or other attributes. pkill will signal a process with a matching name or attribute. Want to kill all processes being run by a given user? Issue a pkill -U USERNAME; sure beats the hell out of:

ps -U USERNAME|awk {'print $1'}|xargs kill

2. htop – Much like your regular ‘top’ command, on steriods. Gives an interactive view on your machine right now, but with an ascii visual representation of your CPU, memory and swap utilisation. Often not installed by default, but is packaged under both Red Hat Enterprise Linux and Debian and can be trivially installed on most dedicated and virtual private servers.

3. mytop – Similar to top, but designed specifically for MySQL. Gives you an interactive display of what is happening with your MySQL database, in real time. Information such as what queries are being run, amount of data which is being flowing in and out of the database, number of queries being run per second and number of slow queries. This application is once again packaged with most large common Linux distributions.

4. lsof – This cool little command comes with most Linux Distros as default and allows you to display any files which are currently opened on the system. Especially handy for finding files which have been deleted (and not appearing in the file system) but still resident due to being held open by a current running process.

5. iptraf – Want to know where all your network traffic is going to and coming from? iptraf is a really cool tool which can be used to track this information and let you know what is happening on your server.

I hope this information helps. Got some which I’ve missed? Please leave a comment and make this article more useful!

Anchor is a world-wide leader in providing comprehensive support on dedicated servers and virtual private servers both in Australia and around the world. Speak with our team of system administrators to find out how we can help you: support@anchor.com.au or just read about how we built Github

5
Comments

Why A “Dedicated” Support Technician Is A Bad Idea

Published April 23rd, 2009 by Davy Jones

An emerging trend nowadays is that a lot of businesses have trouble differentiating themselves from their competitors. At this point they usually need to innovate, so they have a “novel” product to sell, or change the way they do business to make themselves more appealing to customers (of course another option is to start slashing prices in an attempt to soak up some of the market, but this simply isn’t sustainable, making it a risky gamble).

Anchor is no exception to this – we firmly believe that our success is in no small part thanks to our quality of customer support and technical prowess. One suggestion that often arises when discussing how we can Do It Better is somehow building better relationships with our customers. The better we understand their goals, the more effectively we can help them.

A lot of other business turn this into a selling point, by offering you a dedicated account manager or point of contact. It’s easy to see why; it makes people feel special, and that makes them feel good – feel-good customers are happy customers. For the business, it’s fairly cheap to do, too. We do this a bit too, but in a less formal manner. A staff member with a lot of experience with one customer tends to pick up their support requests anyway, which works out nicely.

In a perfect world, all else being equal, having someone who knows all your history and systems inside out is much better than having different people work on your business each time you make contact. In the real world, however, it’s never that simple. We’re all for promoting stronger customer relationships, but it’s important to recognise that this can add weaknesses if not done carefully.


Things to think about

    drunkcat2

  • When your tech goes to the pub, what do you do?
  • When your tech leaves the company, what do you do?
  • Documentation is the key, someone who doesn’t need to document things regularly probably won’t
  • A lack of documentation means that anyone else who does have to work on your stuff is working completely blind
  • Having someone write notes about their clients when they’re leaving is too late, they’ll forget too much stuff
  • Pub/hit-by-a-bus problems don’t give the luxury of pre-departure documentation, anyway
  • If you’re running multiple technologies, perhaps different people will be the best to work on the different parts of your system anyway
  • Is your “dedicated support person” actually a tech, or just an account manager who acts as a gopher between you and the real technicians? If so, they’re just overhead, and could quite possibly make things harder by slowing down communication and not properly communicating things back and forth
  • Some companies will advertise “dedicated support tech” because they’ve only got one person in their support department!

For these reasons we do not believe in providing a “dedicated support person”. What we do offer, however, is access to a team of well trained and experienced system administrators who are all capable of assisting with all your hosting infrastructure. That said, we’ll do our best to get the most appropriate person onto your problem, whether that’s someone who knows your particular setup or someone who is an expert at the technology you’re using or even the particular problem that you’re having. To ensure there is continuity of information across the team we use a ticketing system to make sure that everyone readily has access to all historical information about an issue, and finally, we have a very healthy appreciation of the value in having comprehensive documentation about everything we do.

0
Comments

Reduce Linux VPS/VM guest memory usage

Published April 6th, 2009 by Paul De Audney

Reducing the memory usage in your VPS/VM can be a great way to free up some resources to handle more requests, users or some other metric of win.

By default at Anchor we provision our Red Hat & Cent OS VPS servers with a trim memory usage profile by disabling a lot of unneeded services at install time. We do this by using Trogdor (our hardware/software burninator) and Puppet.

So just what services do we disable, if they exist on the new VPS?

  • gpm
  • netfs
  • pcmcia
  • sgi_fam
  • yum-updatesd
  • pcscd
  • rhnsd
  • xfs
  • hald
  • hcid or sdpd
  • hpiod or hpssd.py
  • dbus-daemon
  • cupsd

You can also reap performance gains by changing how you serve content. For example you can use a cut down high performance web server (nginx or lighttpd) to serve all static content, such as images. Then use an Apache process to handle your dynamic requests.

Tuning Apache is deserving of an article all to itself, however some hard and fast rules are:

  • Disable all unnecessary modules.
  • Work out the per process memory usage, and set your max clients to a suitable number taking into account the available memory and other system daemons.
  • Disable htaccess if you do not need it.

PHP is much the same as Apache, disable what you do not need. This goes for any service or application with many optional components.

3
Comments

VMware ESX Guest Disk IO

Published April 6th, 2009 by Paul De Audney

Knowing the state of your disk IO latency in VMware ESX can help you pre-empt performance & capacity issues before the occur. There are a few guidelines you should keep in mind. These notes are directed towards people using directly attached storage.

  • Write latency should be 0, because you have that fancy battery backed controller caching writes, right?
  • Read latency should be under 8ms.
  • Use the smallest stripe size possible for your RAID array setting. This helps keep random IO performance acceptable at the cost of some sequential performance.
  • Do not virtualise very heavy random IO workloads on shared arrays, other guest VMs wont like you for it.
  • Unless you have a very compelling reason not too, use RAID 10.

Some other notes, specific to Linux guests are:

  • Mount file systems with noatime and nodiratime, this will help reduce random IO.
  • Allocate enough memory to have some buffers.
  • Do anything possible to stop your VM swapping heavily (see point above).

As with any system, having great monitoring and performance trending allows for you to have an excellent overview of your infrastructure. Even if you don’t have external systems for performance trending, the VMware Infrastructure client with a few tweaks will display the data you want to see.

  1. Login to the VI Client.
  2. Click on an object in the left navigation tree.
  3. Click on the performance tab at the top of the main display pane.
  4. Click the “Change Chart Options” button
  5. Select the Disk chart option from the left expanding menu.
  6. Now change the counters, pick the Latency counters and Number counters, un-ticking the KBps  counters.
  7. Save the chart settings as disk-latency.

Now you can view in real time what is happening with your disk IO on the VMware ESX server. If you are more familiar with using a command line and Linux, you can SSH in to the ESX COS and use the command esxtop to view disk performance information.

  1. Launch esxtop (as root)
  2. Press “v”
  3. Press “s” and then “1″

Now you can see the per VM disk usage counters, with a 1 second sample period.

These rules of thumb are also applicable to Xen and Hyper-V.

0
Comments

Safely handling RAID failure

Published March 9th, 2009 by Davy Jones

With hard discs being by far the most common point of failure in servers RAID does wonders for protection against loss of data.

With a RAID array in normal operation we’re in a pretty safe place. We know that we can suffer failure of a drive without loss of data or disruption of service. Once a drive has failed however we’re in a slightly more precarious position. Loss of another drive or damage to the remaining drive could easily cause major problems. At this point the only thing that can protect you can against data loss if you make a mistake is your backups – you did configure backups didn’t you?

Restoring a damaged RAID array is a task that requires extra caution. 

On our range of dedicated servers and vps‘ it’s one of those things that just happens automatically and the client usually only finds out after the problem has been fixed. For our co-location customers however it’s a task that we often find ourselves involved with to lend a helping hand.

With this in mind we’ve started to put together a series of articles discussing the steps we take to restore a Linux RAID array after hard disc failure and recoving from a Windows software RAID failure We hope you find them useful.

0
Comments

VMware announce the new VMware 4 named vSphere

Published February 26th, 2009 by Paul De Audney

VMware have just announced that the new version of VMware ESX will be called vSphere.

Some of the announced features are:

  • 64bit kernel and console operating system (COS)
  • clustered VirtualCenter Servers
  • ESX hosts profile management
  • cross-hosts virtual networking
  • 8-way virtual SMP
  • virtual machines fault tolerance across multiple hosts (the famous Continuous Availability presented last year)
  • VMs and media library
  • alarms on physical hardware faults
  • access control on storage resources
  • configuration change tracking
  • full support for SATA local storage

So it seems VMware are catching up to Xen with some of the features. There will be interesting times ahead in the virtualization space, with the recent release of Citrix XenServer for free.

With an updated kernel and 64bit COS, end users should see more hardware end up on the compatible list which is good news for those who want to use some of the latest and greatest hardware.

Additionally 3rd party vSwitches are going to be supported. Cisco have demoed their Nexus 1000V with vSphere.

0
Comments

Firewalling VMware ESX for console access

Published February 23rd, 2009 by Barney Desmond

One of Anchor’s more recent product offerings is VMware-based virtual private servers. As one of my colleagues has already detailed, we take extra measures to secure the VMware host server to reduce the possibility of a compromise.

Our VPS offering uses VMware ESX, which runs on bare metal and doesn’t have a host operating system. This isn’t the full story – according to documentation it boots a Redhat Enterprise Linux 3 system, then loads the vmkernel which is where the real work is done. One of the nice things about this approach is that there’s a userspace environment in which to run support software, like good monitoring components.

We ran into an odd problem recently with an ESX host server on a dedicated network segment, namely that we couldn’t view the console for VM guests. Nothing would happen for about 30 seconds, then the VMware Infrastructure Client (VIC) would report a connection failure.

Most people using VMware now have probably used the vanilla VMware Server once or twice. It’s pretty easy to understand, and because it runs on top of your usual OS, firewalling it as simple as opening holes for legitimate clients to connect to TCP port 902. That’s not the case with VMware ESX, and without reading the manuals it’s not immediately obvious what the problem is.

As it turns out, the VIC is attempting to connect to TCP port 903 on the host server. If one assumed that the VMware hypervisor is just a modified linux system (which is what it looks like, but isn’t quite) you should be able to see a listening port in the output of netstat -tnlp, but you can’t.

[root@miyuki root]# netstat -tnlp
Proto Local Address       Foreign Address     State       PID/Program name
tcp   0.0.0.0:5666        0.0.0.0:*           LISTEN      2684/nrpe
tcp   127.0.0.1:32771     0.0.0.0:*           LISTEN      1807/cimserver
tcp   0.0.0.0:5988        0.0.0.0:*           LISTEN      1807/cimserver
tcp   0.0.0.0:5989        0.0.0.0:*           LISTEN      1807/cimserver
tcp   127.0.0.1:8005      0.0.0.0:*           LISTEN      1652/webAccess
tcp   0.0.0.0:902         0.0.0.0:*           LISTEN      1598/xinetd
tcp   0.0.0.0:199         0.0.0.0:*           LISTEN      1489/snmpd
tcp   0.0.0.0:8009        0.0.0.0:*           LISTEN      1652/webAccess
tcp   0.0.0.0:80          0.0.0.0:*           LISTEN      1765/vmware-hostd
tcp   0.0.0.0:8080        0.0.0.0:*           LISTEN      1652/webAccess
tcp   0.0.0.0:22          0.0.0.0:*           LISTEN      1498/sshd
tcp   127.0.0.1:8889      0.0.0.0:*           LISTEN      1839/openwsmand
tcp   0.0.0.0:2265        0.0.0.0:*           LISTEN      1732/osirisd
tcp   0.0.0.0:443         0.0.0.0:*           LISTEN      1765/vmware-hostd

As a little more reading revealed, the VIC makes an extra connection to port 903 for console data. This marks a significant change from the earlier model of passing everything through the same connection, and the reason for such a change is unclear.

We’ll assume there’s some performance benefit to be had there. What we find more interesting/important is that port 903 is entirely “under the radar”, as it’s implemented in vmkernel. The other traffic on the box is subject to our standard iptables rules as far as we can tell, including port 902, which is used for a lot of other management-client to host-server interaction.

tcpdump is also oblivious to port 903, so we’re guessing VMware passes traffic through the netfilter stack when it’s deemed to be convenient or necessary. If we had a spare ESX host sitting around doing nothing, I’d be interested to see if the packet counters shown in the output of ifconfig are also affected.

0
Comments