What is anycast? Anycast explained at a very basic level
Anycast, at a very basic level, is when a collection of servers share the same IP address and data is sent from a source computer to the server that is topographically closest. It is important to remember that topographically closer does not inherently mean geographically closer, though this is often the case.
Anycast is used primarily for load balancing to allow the server topographically closest to a user to handle their request. This helps cut down on latency and bandwidth costs and improves load time for users.
Anycast is linked with the Border Gateway Protocol. This is a protocol used between routers on the Internet with the intent of ensuring that all of a router’s neighbours are aware of the networks that can be reached through that router and the topographical distance to those networks. The principal of Anycast is that a single IP address is advertised in the BGP messages of multiple routers. As this propagates across the Internet, routers become aware of which of their neighbours provides the short topographical path to the advertised IP address.
IP addresses used in Anycast are often purchased directly from a Regional Internet registry. Some data centers are known to rent IP addresses to customers and allow them to be advertised by other data centres.
As with all routing, it cannot be guaranteed that a packet will take the same path across the Internet as its predecessor. With Anycast, it cannot be guaranteed that a packet will reach the same destination server as its predecessor. As such, Anycast is not suitable for protocols which track state. TCP is an example of one of these. UDP, however, is perfect for Anycast providing it does not try to track state at a higher level of the OSI model and that the application layer protocol does not rely on a large number of fragemented datagrams to transfer data.
The typical scenario for Anycast as a load balancer is thus:
- A server in London has its own IP address 3.3.3.3 and a shared Anycast IP address 1.1.1.1.
- A server in New York has its own IP address 4.4.4.4 and a shared Anycast IP address 1.1.1.1.
- Each of the above servers runs a DNS server listening on 1.1.1.1.
- The DNS servers serve up an A record for anycastdomain.com. London would serve up 3.3.3.3 and New York would serve up 4.4.4.4.
- When a DNS request is made for anycastdomain.com, Anycast would route this request to its topographically closest DNS server. This DNS server would, in turn, serve up the unique IP address of its own server and a TCP connection would be established over standard unicast.
Feedback from companies such as ScaleEngine is that it’s quite difficult to persuade data centres to add IP addresses to their BGP. This appears to be best suited to larger organisations who lease their own transit and have BGP agreements with their transit providers.
Why I don’t like database stored proceedures
There’s a number of compelling reasons not to use them. Here’s just a few:
- They can’t be stepped through and debugged by your standard IDE. Admittedly, neither can the other dirty SQL you shove in your code however because the majority of SQL lacks logic beyond IF() this is less of a problem.
- The errors created by the DBMS on the failure of a stored procedure are often very cryptic and relate to an underlying database error caused by a single line in the stored procedure.
- You’re passing off the processing load to your database server. Databases, for example MySQL, are a lot harder to scale than hosting environments such as PHP-FPM. Research shows a very marginal performance boost in using stored procedures but I don’t think that this is enough to hide the fact that your database server will process less transactions per second.
- You lose portability. A good database abstraction layer in your code should make it portable between databases. Using stored procedures negates this.
- In the words of @altreus… they’re not in the code base, they’re not in the code base, they’re not in the code base. As such, they don’t track via version control systems. Of course, your database migrations should contain the stored procedures but each change is a new file. This isn’t how version control works.
- Further to the above, they’re anti-version control. Not only must a developer have his own version of a codebase, he must also have his own version of the database. When working in a team, this adds further complexities and makes it a fruitless task for individual developers to unit test builds prior to committing.
- Stored procedures aren’t reusable in the same way that code is. This is because they lack library support.
Any number or indeed all of the above may be total bollocks. Nevermind. At least it’ll serve to troll those in favor of stored procedures.
Add funds instantly with PayPal’s new feature
I stumbled across this the other day and can only assume it’s a new feature. I’m in the UK so if anyone could verify if it’s also on PayPal US, that’d be great.
When adding funds to your PayPal account, there’s now 2 options:
Adding Funds with PayPal
The left hand one is the interesting one. Using it allows you to make a direct transfer from your bank to PayPal. The money showed up within seconds. This is particularly useful as it makes PayPal a more viable option for paying friends and family as PayPal payments which are funded from PayPal funds (within the same country) don’t carry any fees.
I have also dealt with a few companies who accept PayPal but charge a hefty surplus to cover the fees. Using this option allows you to pay them instantly and not incur such an excess.
Installing pfSense on a Watchguard Firebox x550e and x750e
I’ve done this enough times to be confident that it works. There’s some great instructions written by Daniel Bernhardt which cover the topic pretty well. Here’s a few things I’ve found:
- Some Fireboxes come with pre-installed 512MB CF cards whereas most come with 256MB cards. If you’re unlucky enough to get a box with a 512MB card, you’ll need to purchase a 256MB card for flashing the BIOS. The 512MB card will not work for this purpose.
- When Daniel notes that the “Baud Rate is going to change” it’s a little unclear what should be done here. You should allow the Firebox to boot until you start seeing gibberish coming out of the serial port. At this point, connect to the firebox with a baud rate of 115200 and power cycle it. After this, you can change the BIOS settings.
- Use a fast compact flash card. I’ve had a lot of problems on pfSense 2.1 with slow CF cards. A 200x card works great. I used a Sandisk 4GB 30MB/s card. This has the side effect documented here but this is purely cosmetic and does not affect the running of the system.
- The firebox has a spare RAM slot. This will happily take an extra 512MB DDR2 PC2-4200 533MHz DIMM to give your router a bit of a memory boost. These DIMMs are going so cheap on eBay it’s silly not to.
- At time of writing, the LCD screen is supported natively by the LCDproc-dev package. To use, do the following:
- Install the LCDproc-dev package
- Go to services->LCDproc
- Tick “Enable LCDproc at startup”
- Select the “Watchguard Firebox with SDEC (x86 only)” driver
- Leave everything else as is
- Click Save
- Tick the “Screens” that you want to show on the screens tab
- Go to status->services and start the LCDProc service
- Use the up/down button on the firebox to turn on the back-light and move between “screens”
This firebox range has turned out to be fast and reliable on production networks.
Edit: As per Stephen’s comment below, here’s a definitive reference source for Pfsense on Watchguard Firebox devices.
Below are mirrors of the files hosted by Daniel, just in-case they’ve vanished. These are possibly out of date. Use the pfsense docs link above as the definitive source.
The image for flashing the BIOS
The BIOS
WGXepc
MD5 sums of all the above
How to get a status update out of a running dd process on Linux
With dd running in a terminal, open a new terminal to the server and send the USR1 signal to the dd process. You can either do this by looking up the process ID and doing:
- kill -USR1 pid_here
Or use killall to send the signal to all dd processes:
- killall -USR1 dd
You’ll see output similar to this in the terminal dd is running in:
- 45900+0 records in
- 45900+0 records out
- 752025600 bytes (752 MB) copied, 541.855 s, 1.4 MB/s