IPv6 and the Internet of Things

By Nick Hardiman

January 14, 2013, 7:00 AM PST

Takeaway: Nick Hardiman explains why the switch to IPv6 will further enable the world of connected devices.

The Internet of Things means the continued growth and development of an open, global Internet. The tool that is going to make that possible is IPv6, and organizations from the IEEE to ISOC have been pushing it (World IPv6 Launch Day was June 6, 2012). But what is it good for? Is it just about replacing IPv4 addresses like “213.138.103.126″ with weird looking IPv6 addresses like “2001:41c8:51:27e::10″?

Getting from nothing to something

IPv4 was the main tool used to create the global Internet. It was an IT success story, of getting from nothing to something for everyone. It wasn’t perfect, but the history of IT success stories is full of examples of dodgy decision-making. Using two ports for FTP probably seemed like a good idea at the time. Tying Ethernet MAC addresses to their manufacturers probably wasn’t the greatest security decision. A URL really doesn’t need :// stuck in it.
As an example, take the IPv4 address. It looks something like this: 1.2.3.4. That IPv4 address format is called dot decimal notation, and it is a little whacky. It’s a coding system that turns the 32 bits that a machine can read into four decimal octets for humans to read. It isn’t really decimal, it isn’t really binary, and it certainly isn’t octal. This dot decimal system helped IT people remember IP addresses, at a time in IT history after they had agreed that splitting code into 8 bit chunks was useful and before they had realized this shorthand notation would escape and find its way into every home and office in the world.

Getting from something to something better

Jumping from version 4 to version 6 will simplify the networking world. The simple fact that IPv6 has a zillion addresses means the workarounds used with IPv4 can be removed. The simple Internet model of sending a packet from one address to another was broken with NAT (Network Address Translation).
With IPv6, there is no need for private addresses. Most enterprise computers have private IP addresses, so making the most of IPv6 in an enterprise will require quite a shift in working practices.
IPv6 can also make current practices redundant — IP address block land grabs, the IP pools of ISPs, and even the client/server model could disappear.

Should I switch to IPv6 in 2013?

For an enterprise, yes - well, partly. For a residential user, no.
When an enterprise refreshes its technology, it makes sense to have a strategy that insists on new kit that can handle IPv6. It makes sense to build new IPv6  services alongside new IPv4 services. There is no pressure to upgrade existing services to use IPv6.
At home, most of the components needed to make sure IPv6 replaces IPv4 are already in place. The popular operating systems can talk IPv6. Most home computers understand IPv6, and so do many home routers. Many Internet services have IPv6 addresses. Unfortunately, many people can’t reach them because their ISP only does IPv4 - if a residential early adopter wants to reach an IPv6-only website, she may be out of luck. It’s going to be a while before IPv6 becomes the norm in domestic networks.

Can I face the change?

And there’s the learning curve that comes bundled with every new technology. I know I ought to learn about IPv6 and change my servers that only use IPv4, but I am not excited by the prospect. It feels like a low-priority chore, and keeps slipping to the bottom of my to-do list. After many years in the Internet industry, I remember IPv4 addresses like I remember birthdays (the really important ones stick, but I need reminding about the rest).  I haven’t thrown enough IPv6 addresses at my memory for any to stick.
I will learn, and I will change my servers. IPv4 enabled the Internet and IPv6 will enable the Internet of Things. If I want a future in Internet IT, I must update my skills. IPv6 and the Internet of Things are the future.

source: http://www.techrepublic.com/blog/networking/ipv6-and-the-internet-of-things/6278?tag=content;siu-container

Disk-based backup data: Where to put them?

By Rick Vanover

January 30, 2013, 6:00 AM PST

Takeaway: This is an age-old question, and the answer may not be as simple as you think. Rick Vanover shares his thoughts on the best way to provision storage for availability.

I don’t know about you, but every time I turn around I see a new way of doing storage that I have to sit down and think about. Things such as new protocols, new products, and new disks make our ‘standard’ processes subject to revision at any time. One thing I’ve learned over the last few years about disk-based backups is that there are plenty of things that can go wrong. So, I thought it worthwhile to explain a few points that I’ve learned over the years so you can help provision your storage resources to avoid some of the pitfalls I’ve seen (and experienced myself!).

NFS vs. CIFS

The first storage question I usually address is, “Should I use NFS or CIFS?” CIFS stands for Common Internet File System and the newer version of that protocol is SMB (Server Message Block). NFS is Network File System and has deep UNIX and Linux roots. But it is important to note that CIFS isn’t really CIFS anymore, and it’s now effectively SMB, making CIFS uncommon. CIFS is an older file protocol that Windows has supported, but now heavily favors SMB. We may naturally prefer to use CIFS because it is easy. I spend most of my time in Windows, and NFS from Windows is really not pleasant (though it is much better with Windows Server 2012).
So, because of this plight; many people choose to put their backups on a CIFS or SMB resource. That’s all fine until one critical situation. The backup that needs to be restored is part of the Active Directory domain. When it comes to accessing this storage, simply using CIFS or SMB may require that Active Directory be running. The moment your restore scenario becomes hosed because you can’t log into the storage resource, you can realize the problem. In this situation where the storage resource requires Active Directory to access the backup data for its CIFS or SMB implementation, NFS may be a better choice. Since it uses Linux authentication, Active Directory isn’t required. This is especially helpful should the restore be of Active Directory. Trust me: I’ve learned that one the hard way.

SAN gotchas

Another tip related to disk-based backups I’d like to share is considering domains of failure on block-based storage resources such as a SAN. I’ve seen a number of situations where a SAN controller provides multiple disk tiers or arrays and backup data is put on the different disk channels. This could be as simple as the SAS (higher speed, higher price, lower capacity) drives contain the running data profile (VMs, servers, LUNs, etc.) and the SATA drives (lower speed, lower cost, higher capacity) contain backups of the other disk profile. That’s great until the SAN controller fails, making both drive arrays inaccessible. I know most storage systems are built with dual-controller systems, but if it can go wrong, it just may. Same goes for the storage network in place. If the storage network itself (Ethernet, iSCSI, Fibre Channel, etc.) fails, does that remove access to storage for the recovery scenario?
There are plenty of things that can go wrong, but what do you do to your storage for disk-based backups to ensure that they are kept available? Any tips you can share? Start a comment below!

Source: http://www.techrepublic.com/blog/networking/disk-based-backup-data-where-to-put-them/6328?tag=nl.e102&s_cid=e102