Amazon Glacier: 99.999999999% durability long-term storage, for a penny a gig

Amazon has unveiled the latest addition to AWS: Glacier, a long-term, cloud-based storage solution that costs just $0.01 per gigabyte per month. This is significantly cheaper than on-site storage, and at least ten times cheaper than other cloud storage services (such as Amazon S3, Dropbox, Azure, and so on.)

Amazon Glacier is just like Amazon S3, but it’s designed explicitly for long-term storage. You upload your data, and then Amazon automatically duplicates the data across multiple geographically diverse repositories, promising 99.999999999% durability (if you store 10,000 objects in Glacier, you might lose one object every 10 million years). In short, you will only lose Amazon Glacier data if there’s some kind of apocalypse.

Unlike S3 or other cloud storage, which is “online” and always available for instant access, retrieving data from Glacier takes time — between 3 and 5 hours — and costs a significant amount of money (more than 10 cents per gig). There is also a $0.03 penalty per gig if you delete data within 90 days. If you store 100 terabytes in Glacier, you’re looking at around $10,000 to retrieve everything.

There is one rather important exception, though: In a given month, you can retrieve up to 5% of your total storage for free; so if you store 100TB, you can download 5TB per month for free. This fits in very well with the normal use-case for long-term storage (it’s very unlikely that you’d need to download the complete, 100TB, 20-year archive).

The key to this service is the 3-5 hour retrieval window, which is caused by Amazon using a robotic tape library. We don’t know the exact structure of Glacier, but it likely has a bunch of hard drives on the front end, acting as a cache for recent and regularly retrieved files, and then an absolutely massive tape library. When you make a retrieval request, a robotic arm grabs the tape with your data in, slots the tape into a drive, and then your data will be transferred to a hard drive ready for you to access. The 3-5 hour window is simply be the time it takes for the robotic arm to become available — if a lot of people are making retrieval requests, you have to wait in line.

Tape libraries can store a truly stupendous amount of data. Spectra makes a range of robotic devices that have 24 drives and space for 1,000 tapes — and these can then be networked together to create a library with a total capacity of 3.6 exabytes (3.7 million terabytes). It is likely that Amazon has built quite a few of these libraries at its data centers in the US, Europe, and Asia.

Rounding out the service, Amazon S3 users can easily transfer data directly into Glacier — and in the next few months, Amazon will allow AWS users to configure lifecycle policies that automatically move data from S3 to Glacier.

Amazon Glacier is, at least from the outset, almost perfectly placed. Managing long-term backups is hard work and very expensive, and there are a lot of companies that wouldlove to shut down their aging NAS and tape libraries and switch to Amazon. At just a penny per gig per month, Amazon Glacier will be more reliable, extensible, and cost effective than in-house solutions. The only real problem that I can foresee is data security — but considering you could just encrypt all of your data before sending it off to Glacier, the risk of someone cracking into your data is minimal.

Read: How big is the cloud?

Source

Google Compute Engine: For $2 million/day, your company can run the third fastest supercomputer in the world

At the Google I/O conference in San Francisco, Google has announced the immediate availability of Compute Engine, an infrastructure-as-a-service (IAAS) product that directly competes with Amazon EC2 and Microsoft Azure. Citing more than a decade of running and optimizing its own data centers and network infrastructure, Google is claiming that the Compute Engine is more scalable, more stable, and cheaper than the competition.

For this story, we’ll focus on scalability and cost (I’m sure that Compute Engine is stable, but Google just hasn’t given us any figures to work with). Google says that Compute Engine has access to 770,000 cores — a figure that will surely grow over time. In one demo at Google I/O, a genomics app (it analyzed the human genome) was shown to use 600,000 cores. These cores are made available as Linux virtual machines (VMs), with 1, 2, 4, or 8 cores each. Each core apparently has access to 3.75GB of RAM each — and, of course, each VM is connected together using Google’s advanced networking technologies and topologies.

777,000 cores, assuming the entire Compute Engine cluster consists of 8-core CPUs, equates to 96,250 computers. This is a huge number — probably equal to the total number of servers operated by Intel, or data centers such as The Planet or Rackspace, but considering Google is estimated to have more than 1 million servers in total, it’s not that huge. Amazon EC2, by comparison, is estimated to have around 450,000 physical machines. Still, almost 100,000 servers on your opening day is rather impressive; Google is obviously starting as it means to go on.

For an interesting reference point, Sequoia, the world’s fastest supercomputer, has 1.78 million cores (clocking in 16 petaflops). Number two, the K computer, has 700,000 cores (10.5 petaflops). During that Google I/O demo, by using 600,000 cores, that genomics app was probably hitting the Compute Engine for somewhere between 1 and 10 petaflops of computational power — between 1 and 10 quadrillion calculations per second. For a few moments, the Compute Engine was probably the third fastest computer in the world.

But at what cost? The Google Compute Engine website says that an 8-core VM with 30GB of RAM costs $1.16 per hour. For 600,000 cores, you need 75,000 VMs — so, $87,000 per hour, or $2 million per day (and that’s before bandwidth and I/O costs). Even so, that price is actually quite reasonable, when you consider that supercomputers generally cost tens of millions to install and millions per year in running costs — well, as long as you don’t need the Compute Engine for more than a few days per year…

Finally, compared to “other leading cloud providers,” Google is claiming that Compute Engine gives you 50% more bang for your buck — though the company didn’t go as far as calling Amazon or Microsoft out. A quick glance at the Amazon EC2 pricing page suggests that Google’s $1.16/hour is actually more expensive, but perhaps it isn’t an apples-apples comparison.

Read more about the size of the cloud — or the size of porn sites

Source

New Bulldozer deep dive sheds fresh light on AMD’s troubled CPU

Of all the CPUs launched in the past decade, none has been as puzzling as AMD’s Bulldozer. While it’s been widely derided as AMD’s version of Intel’s Pentium 4 Prescott, even early analysis indicated that such comparisons were fundamentally flawed. Bulldozer was an ambitious design to fuse chip logic and improve performance, but teasing out why it didn’t work has been a long, difficult process.

Thanks to Johan De Gelas over at Anandtech, we now have considerably more information on what doesn’t work, and some insight into how AMD can fix it. De Gelas used analysis tools from AMD and Intel to gather data on how Sandy Bridge, Magny-Cours, and Bulldozer/Interlagos execute various workloads and where the performance bottlenecks lie. Conventional wisdom, including my own articles, implied that Bulldozer’s high L2 cache latency was a major factor in the chip’s disappointing performance. His findings indicate that cache latency isn’t the problem I thought it was, at least not in server workloads.

Death by a thousand cuts

There are two major problems undermining Bulldozer’s performance in server workloads. First, there’s the issue of branch prediction. Bulldozer’s branch predictor is more accurate than Magny Cours’, but Interlagos takes a 20-cycle penalty in the event of a missed branch, whereas MC’s penalty is 12 cycles. As Johan explains, this is where comparisons to Prescott miss the mark; Prescott’s branch prediction penalty could be as high as 100 cycles.

Sandy Bridge’s branch prediction penalty is actually also fairly high, at 17 cycles, but Intel uses a 6K decoded µop cache that brings the penalty down to 14 cycles if the instruction is found there. This is one avenue AMD could potentially explore to improve the chip’s performance.

L1 cache associativity is the other issue discussed in-depth. We’ve known for quite some time that Interlagos’ efficiency suffers when both modules are enabled; additional evidence suggests that flipping on both modules in an Interlagos core doubles the number of L1 cache misses in certain workloads. Increasing cache associativity could help counter this.

Anandtech hints at (but does not disclose) a fourth “showstopper,” which leaves clock speed as the final factor. Here, there’s evidence of improvements in the latest Piledriver core at the heart of AMD’s Trinity. Piledriver uses what are known as “hard flops” and a resonant clock mesh to reduce power consumption and improve clock speeds. AMD claims Piledriver delivers a 10% reduction in dynamic power consumption compared to Bulldozer, with certain workloads improving by as much as 20%.

Putting it all together

The data suggests that Interlagos’ future in the datacenter is more hopeful than some have thought. The clock speed improvements built into Piledriver should allow that CPU to compete more effectively against Intel’s Xeons when it launches later this year, even if the other improvements to the CPU’s branch prediction and IPC have only a small net impact.

The client roadmap is a bit murkier. Here, the high L2 latency is a much greater factor and there are precious few desktop apps that scale well beyond four cores. Higher clock speeds will still improve the competitive situation, but high cache latencies are the architectural equivalent of millstones around the architecture’s neck.

It’s entirely possible that we won’t see these problems truly addressed until Kaveri, the 28nm successor to Piledriver scheduled for 2013.

AMD’s roadmap still shows Vishera (aka Piledriver) holding the top of the performance spectrum, but its Kabini that integrates a third-generation Steamroller core. None of AMD’s roadmaps currently show a server/high-end desktop Steamroller variant; it’s not clear how the next-gen core transitions into the product line. Kabini will be the first AMD APU to integrate a GPU based on the company’s current 28nm hardware, but we suspect it’ll be a few more years before servers are able to consistently leverage the graphics cores in every day workloads.

Still, there’s reason to be marginally more optimistic about AMD’s long-term ability to scale the Bulldozer architecture. We don’t expect it to challenge Intel’s performance any time in the near future, but some of the more pessimistic appraisals of its scalability may also turn out to be misguided.

Source

IBM concerned about Siri’s loose lips

IBM is worried about Siri and will prevent iPhones from accessing the virtual assistant while connected to the company’s internal network. Chief Technical Officer Jeanette Horan says IBM blocks the servers that power the software, fearing a security risk or information disclosure of corporate data.

When asking Siri a question, recordings of the question are sent to Apple’s servers where it is analyzed. Apple has not been too forthcoming on what is done with these files, if those files are stored ,and for how long if they are. This makes IBM uncomfortable, enough that it decided to ban the app.

“We’re just extraordinarily conservative. It’s the nature of our business,” Horan explains.

While the company’s move seems extreme, it stems from a legitimate concern. Companies big and small are struggling with employees’ desire to use their own devices in the workplace. The reasons for doing so vary: some prefer to use a platform they’re familiar with — say OS X over Windows, or Windows over Linux — or they want personal freedom, such as the right to access social networks or instant messaging clients while at work.

This presents a security problem for IT administrators. Admins can’t control what we’re doing on these devices quite like they can on company owned equipment, so it results in actions like the one IBM has taken.

Is Siri truly a threat to corporate security? That’s questionable. It’s hard to imagine what IBM employees would be asking or telling their phones that would truly put the company at risk. It seems more an issue of employee discipline than anything that Apple would do.

Above and beyond that, what would Apple truly gain from spying in on the actions of IBM employees? Probably not much. The moral of the story here seems to be that if you value your job, and are working on some pretty secret stuff, it’s your own responsibility to make sure it doesn’t slip out.

Source

AMD detonates Trinity: Behold Bulldozer’s second coming

It’s been a turbulent 12 months for AMD. Since the company launched Llano, its first mainstream “Fusion” part, it has replaced its CEO, brought in multiple new executives, debuted a disappointing architecture,delayed its next-generation Brazos parts by a full year, and outlined a comprehensive vision of the future that de-emphasizes cutting-edge process node transitions in favor of re-useable IP blocks that can be shared between multiple SoCs (system-on-a-chip).

When it launched last year, Bulldozer ran hot, scaled poorly, and was less efficient than its predecessor. When it came to building Llano’s successor, AMD clearly had its work cut out for it. We won’t belabor that point further; if you want more information, check our previous coverage.

We’re guessing that Trinity (the code name) is a nod to the fact that Trinity (the APU) contains a new CPU, new GPU, and new interconnect structure. There’s also a handy reference back to the first atomic bomb test in July, 1945 (this is where Oppenheimer famously said “I am become death, destroyer of worlds” and, of course, to the Holy Trinity. These are both big shoes to fill, so let’s tackle what they’ve come up with, starting with the CPU core. We’ll only be addressing the CPU and GPU here, but a discussion of the interconnect is in the very near future.

AMD claims to have done a great deal of low-level optimization to clean up Bulldozer’s mess. Piledriver’s branch prediction is better, its integer and FPU scheduling makes better use of shared resources, and larger L1 TLBs (Translation Lookaside Buffers) reduce the chance that the CPU will “miss” when searching translated virtual addresses.

Piledriver also adds support for two additional instructions, FMA3 (Fused Multiply-Add) and F16C. FMA3 is a different form of the FMA4 instruction Bulldozer supported. AMD has beaten Intel to the punch on this one; Intel’s own FMA3 support will debut in 2013, with Haswell. Both instructions can improve code execution efficiency by fusing operations and performing them in a single clock cycle, but neither FMA3 or FMA4 is expected to provide significant speed boosts. F16C is a method for converting and storing 32-bit floating point values using 16-bits. AMD might make use of this for the GPU (GPUs have a native 16-bit floating point shader capability), but that’s an unknown as well.

Nearly all of the listed changes are small in and of themselves, but combined, they could make a significant difference in the chip’s overall efficiency. I’m particularly curious about the unspecified “L2 efficiency improvements,” having long suspected that high cache latencies fundamentally sabotaged Bulldozer last fall.

One major feature Piledriver doesn’t change is the number of instructions decoded per clock cycle (4 per module, for a total of eight in a dual-module / quad-core design. That’s significantly fewer than Llano (12 per quad-core) or Sandy Bridge (16). With Bulldozer, it was never clear how much of a role this played in the chip’s lower-than-expected performance.

CPU Performance

Without a test system of our own, we’re forced to rely on AMD’s own published numbers and reviews from other sites. To call AMD’s CPU performance data “cherry picked” is a drastic understatement, virtually every performance score the company provided is GPU-centric or leverages the GPU heavily. The only non-GPU performance data AMD released was in PCMark Vantage and PCMark 7. Those aren’t bad choices for total system productivity — while they don’t rely entirely on the CPU, they’re probably much more relevant to the end-users AMD is courting with these new designs.

Unfortunately, even here, data is extremely limited. AMD’s vaunted claim that Trinity delivers 2x the performance/watt of Llano is based solely on PCMark Vantage’s overall score. AMD claims that a dual-core, 17W Trinity at 2.6GHz essentially ties a quad-core Llano at 2.3GHz, but states elsewhere that an A10-4600M (Trinity, quad-core, 3.2GHz) is only 28.5% faster than an A8-3500M (Llano, quad-core, 2.4GHz). Incidentally, the company’s claim to deliver 28.5% higher x86 performance is based solely on the latter figure.

With dubious and rather contradictory data , our best guess is that Trinity improves on Llano’s overall positioning and offers equivalent performance, clock-for-clock. This will translate into better CPU performance in some SKUs. More important, from AMD’s perspective, was the need to bring Bulldozer’s power consumption down to something that would fit into mainstream and “ultra-light” form factors. Trinity accomplishes this. It won’t compete with Ivy Bridge — matching Llano means it won’t even compete particularly well with Sandy Bridge in CPU-centric workloads — but AMD is pricing these parts into markets well below Intel’s target for IVB and ultrabooks.

AMD’s Cayman – Trinity’s Linchpin

In most literature, AMD refers to Trinity’s GPU as a “Northern Islands” class part without bothering to explain whether it’s based on Barts (a modest step forward from the old 5000 series) or Cayman (the high-end GPU that AMD confined to the 6900 series). Officially, it’s branding the new core as part of the Radeon 7000 family, which isn’t accurate either.

Trying to make sense of AMD’s branding has become murky at best. The 7000M brand is now polluted with three types of GPUs — 40nm rebrands of 6000 parts which arebased on Barts/Turks, 28nm parts based on GCN (Graphics Core Next), and 32nm APUs based on Cayman. Trying to hash out which GPUs are the best match for the APU is a task better left to saints and madmen then poor journalists; we’ll leave the topic of paired graphics for another day.

Unlike Llano, whose integrated GPU was nearly identical to AMD’s discrete “Redwood” part, there’s no easy point of comparison for Cayman. The new GPU features an array of six SIMD clusters of 64 cores each; Llano had five SIMDs of 80 cores. The new GPU is slightly smaller than its predecessor, with 384 cores instead of 400, but one of the features AMD introduced with Cayman was a VLIW4 architecture that was significantly more efficient than the VLIW5 designs that preceeded it. AMD has also increased the number of texture units, to a maximum of 24, up from Llano’s 20. The total number of ROPs remains the same, at eight.

When it comes to game performance, AMD is more willing to share the goodies.

All game tests run at 1920×1080

The company has a bad habit of switching back and forth between desktop parts and laptop parts, and there’s no Ivy Bridge comparison data. Still, things look good. This was very nearly a given; Cayman made a number of efficiency improvements that were logical fits for Trinity, and all of AMD’s APU demos in the run up to launch focused on the GPU.

Trinity moves AMD forward, buys time for 2013 launches

After talking with AMD and reading over the company’s presentations, our educated bet is that Trinity is a qualified success. Piledriver may not move the bar very much on the CPU side of the equation, but between power consumption, temperature, and performance, AMD had to fix the first two to have any chance of launching a mobile part based on the architecture. If Piledriver can match Llano clock-for-clock (or within the same TDP), that’s still significantly more than BD managed when compared to Istanbul/Thuban.

Will it compete effectively against Ivy Bridge? No. But it was never intended to. AMD’s goal with Trinity is to position the CPU as a successor to Llano, a further fulfillment of the company’s “Fusion” vision, and as an anchor in the popular $400-$700 segment. Based on what we’ve seen and a few educated guesses, it’s got a fair chance of pulling it off — short term.

No matter how successful Trinity is in 2012, it doesn’t change the fact that AMD has no traction in tablets or sub-10W designs at a time when companies like Qualcomm have given notice that they intend to move into PCs. That’s fine for the moment, because Windows 8 won’t drop until the latter half of the year, and it’ll take 4-6 months past that point for some of the traditional smartphone/tablet players to make moves into the low-end PC space.

AMD needs a quick jump to 28nm Brazos and a fast refresh on Trinity. In theory, the new chips — Kabini and Kaveri — will be ready in 2013. The company has yet to put a quarter on that number, or to even comment on where the parts are being made. Trinity may be a good beginning, but it’s only that; AMD has a long way to go when it comes to carving out its own territory in between Intel at the top of the market and an onslaught of ARM-based hardware at the bottom.

Source

IPv6 now deployed across entire T-Mobile US network

Yesterday, technical architect Cameron Byrne announced that T-Mobile has completed the deployment of IPv6 services across its entire network. This isn’t the first IPv6 network, but it is the largest wireless IPv6 deployment in the world.

In the announcement, he stated that IPv6 is now available over the main APN for T-Mobile. While there are still a few issues that need to be resolved, the IPv6 service works fairly well for most services. As a result, it will no longer be required to manually request access to IPv6 services. Instead, only a new APN needs to be added to the smartphone’s configuration to make it work. Additionally, T-Mobile is having success getting manufacturers to provide devices that support IPv6 over UMTS networks.

Why is that important? Well, most UMTS devices are designed to only connect over IPv4 in the radio chip to the core network. Even though Android does technically support IPv6 over UMTS, usually only IPv6 over WiFi works on Android. The same is true for iOS and Windows Phone 7.5, too.

As of right now, the only devices that support IPv6 over GSM and UMTS are the Samsung Nexus S for T-Mobile USA and the international unlocked HSPA+ Samsung Galaxy Nexus. The deployment of IPv6 is also critical to T-Mobile’s upcoming launch of LTE next year. LTE uses IPv6 natively across the network, so all LTE devices are IPv6 capable, too. T-Mobile’s HSPA+/LTE devices will be IPv6 capable on all types of supported networks, rather than just LTE and WiFi (which is how Verizon and Sprint LTE devices will work).

Mr. Byrne has updated the website of the IPv6 trial to reflect these changes. If you’re a T-Mobile customer with a Samsung Nexus phone that is compatible with the T-Mobile UMTS network running Android 4.0, follow the steps on the website to activate IPv6 support and begin the “friendly user trial.”

So, will T-Mobile be participating in the World IPv6 Day this June? Sadly, no. T-Mobile will not be participating because it doesn’t have the device portfolio of IPv6 enabled devices to make it feasible for production IPv6 availability, according to Mr. Byrne when asked in a private email about it.

Source

Removing Cisco from the equation with software defined networking

Networks are messy. Although they can be made to look neat and tidy by holding all the gear in rack mounted cabinets with serious cable management makeovers, they are still comprised of small islands of hardware each running its own proprietary software and firmware, often on proprietary silicon. For home users this isn’t really an issue, but for large government and business networks things get complicated and convoluted quickly. Especially in the case of internal networks used by governments that need to be as locked down as possible, changing even one switch, server, or connected device on the network is a tedious (and expensive!) process of rewriting security rules on a each and every hardware device.

Each hardware device (be it a switch, router, server, or firewall) operates as its own isolated island which requires individual configuration. Seeing the shortcomings of such a setup, researchers and startup companies like Nicira have started to develop open software control systems under a coined term of “software defined networking” (SDN). Stuart Miniman defines SDN as “a model for network control, based on the idea that network traffic flow can be made programmable at scale, thus enabling new dynamic models for traffic management.” Similar to the way virtualization can be used to host many (virtual) computers on one physical piece of hardware, these virtualized networks could allow companies to run multiple network slices off of a single physical network.

This is a level of control and programmability that is not currently possible due to network hardware vendors using proprietary software in all their devices (Cisco’s IOS for example). SDN takes the proprietary code out of the equation, and — using open software on all the routers, switches, firewalls, and other network devices — separates the data and control planes (the packets and the logic that determines what to do with those packets). The network hardware is then connected and mapped out in software, and network admins are able to manage the entire network from a software interface. They are also able to specialize their network and add new functionality by writing their own code and deploying it across the network.

One of the most important benefits of SDN is that commodity hardware can be used, instead of specialty hardware from specific manufacturers. Removing or relocating devices on the network would involve a few mouse clicks in a GUI rather than physically switching Ethernet cables and reconfiguring all the appropriate network devices. Martin Casado, CTO of Nicira (who is one of the companies developing SDN technologies) said that “we’re virtualizing away this physical fabric, and because now we have a virtual layer, you can do anything you want with it. Because of this virtualization, the network can be fashioned from any and all compatible hardware, and can be controlled, transformed, and secured from a software interface rather than from configuring each device individually.

There is talk around the web that SDN will spell the end for special network hardwar companies like Cisco as well as eliminate the jobs of network operators. While entirely possible, such an event is not going to happen overnight. Cisco is not likely to give up without a fight, and at this point it still has a chance to react and adapt to this new technology. The reduction in network operator IT positions is possible as well but this virtualization technology is going to open up its own field of study as well, which should lead to positions maintaining SDN. Especially while software defined networking is still a new technology, businesses are going to need their IT personnel.

Networking giant Cisco has recently responded to rumors of SDN killing its business by stating that some customers do not want programmable networks. Also, for those customers that do want the flexibility of SDN, it has funded and plans to acquire network startup company Insieme. Insieme is reportedly working on a line of programmable network switches that support OpenStack as the SDN abstraction layer. The CTO of Cisco has been quoted by Network World in stating “Networking is about to be reinvented and Cisco will do that reinvention of networking.”

In the end, the idea of a truly modular virtualized network that allows control from a software GUI is really cool. It is a big shift in networking to a programmable, open, and modular network controlled via software software that will make managing large scale networks much easier.

[Image credit]

Source

Reliable encryption is essential to the future of the cloud

The gospel in recent years has been that the future is in the cloud. The web will provide the services and storage you need, and it’s safer than keeping files locally. But in the wake of the Megaupload raid, some cloud storage companies are getting cold feet and are rushing to placate the emissaries of the content industry, such as the RIAA and MPAA. All that might add up to a dark and stormy future for the cloud, and your data.

The RapidShare business model is not terribly dissimilar from that of Megaupload. As such, the company has been looking for ways to distance itself from its unfortunate competitor. At the National Press Club, RapidShare recently went a step further by laying out a framework it feels cloud storage providers should adopt to better combat piracy — and it’s straight out of the RIAA’s playbook.

RapidShare suggests that all uploads be scanned for copyrighted content, which would probably put a steak in the heart of fair use once and for all. The plan also indicates the files uploaded should be private by default, with the user being forced to explicitly share a file publicly. RapidShare also says that sites should hire significant numbers of new staff to actively scan user data when there is reasonable suspicion an account is being used for piracy.

To be clear, RapidShare is advocating a system by which a cloud storage provider can look at your personal data if Fox, Universal, or any other content provider suspects you of wrongdoing. Not only does this smack of privacy invasion, it has to make you question the innate security of these services.

Offering automatic encryption of uploaded data is common, but if a cloud storage company can look at your files, that means they have a copy of your encryption key. Some services, for instance Carbonite Backup, allow users to keep the encryption keys private. If RapidShare had its way, standard practice in the industry would be to store your data in a way that it could be decrypted without your consent.

So what’s the alternative if you really want privacy for your data? In this dystopian future, you might have to encrypt your files before uploading them anywhere. Private key encryption is readily available, but it comes with its own challenges. You can’t work with that encrypted data online without decrypting it, thus ending up in the same vulnerable state you were in before. New technologies that rely on different forms of encryption could be a good middle ground, but the service providers will have to support them.

Homomorphic encryption is an exciting idea that would give you much more flexibility in cloud storage. This type of encryption allows you to keep a database in the cloud, work with it, and keep it encrypted the whole time. Imagine that you add two encrypted values, thus getting a result that is still encrypted. Homomorphic encryption can allow you to decrypt that result without ever knowing what the original data said. With this technology, your online database is safe, and you can still work with it easily.

Another option is convergent encryption, which is perhaps a bit less secure, but still better than nothing. With convergent encryption, your personal unencrypted data is used to derive the key that will be used to encrypt it. So with this technology, two identical files will still be identical after encryption, but unreadable without the original file. This would permit a cloud storage provider to scan for known pirated files while keeping your unique personal data completely private.

Even the harsh measures outlined by RapidShare didn’t go over well with the RIAA, which said the proposal fell short of what is needed. We can’t know if any of these policies will become the standard, but copyright holders aren’t going to stop pushing. They’re riding high on the takedown of Megaupload and really seem to want strangers rifling through your files in search of copyright violations. Unless encryption is outlawed, at least we’ve always got that last line of defense.

Read more at Ars Technica

Source

HP to certify Ubuntu 12.04 LTS for its Proliant servers

Mark Shuttleworth has announced at the OpenStack conference that Canonical has received a ringing endorsement from HP in the form of certification for Ubuntu 12.04 LTS on the ProLiant server systems. Responding to customer demand, HP has decided to officially support the popular flavor of Linux giving sysadmins another flexible software option to leverage their current and future hardware.

With Canonical claiming that Ubuntu is the “server of choice” for cloud computing infrastructure, getting the support of a large, well known company in its server arena certainly helps to cement that statement. But with the recent turmoil happening inside Hewlett-Packard, who’s really getting the endorsement here? While it looks on the surface that HP is helping out an idealistic open-source software offering, perhaps the reality is that HP needs Canonical just as much to improve its damaged reputation with confused buyers.

On the technical side, the endorsement announced today basically means that when the Ubuntu 12.04 LTS build is released on April 26th, customers using the software on a ProLiant server will be able to receive hardware warranty support directly from HP. This doesn’t mean that a customer with an installation issue or similar problem can pick up the phone and call HP support, it simply means that by installing Ubuntu 12.04 LTS on their current (or future) ProLiant hardware that they won’t nullify any kind of hardware warranty.

In a phone interview with ExtremeTech Chris Kenyon,VP of sales and Business Development at Canonical, stated that the support of the actual software will remain with his company, and that there are no plans for ProLiant servers to ship with Ubuntu pre-configured. He added, however, that this model was ideal as the cloud computing architects that are building infrastructure want to have flexibility and the ability to purchase their chosen hardware to form the backbone of their operations.

While this certainly may be the case, this announcement can be boiled down to a simple tip of the hat from HP to Canonical to build consumer confidence in the brand. What HP doesn’t want recognize however is the idea that the confidence boost is flowing both ways and is certainly aiding the beleaguered manufacturer.

Canonical has been building momentum lately. The whole Unity debate aside, the releases that have been announced in the past few months have been compelling. While Ubuntu TV may not have been the exciting release we had hoped for, Ubuntu for Android not only makes sense but has me wanting a device that has it installed. Having both a mobile and desktop experience in one device shows a real understanding of where mobile computing is going, and was an excellent step for Canonical. Add in the other recent releases of MAAS, AWSOME, and JuJu and you have three excellent tools for cloud computing architecture that address specific needs that consumers have expressed while working with Ubuntu Server. To use another line from VP Chris Kenyon, “Everything that we have been working on for the past couple of years is crystallizing all at once, things are a bit wild right now.” That statement encapsulates the ride that Canonical is on at the present.

That all being noted, who benefits the most from this deal? While Canonical certainly benefits from a legitimacy point of view, HP stands to gain far more when it comes to improving its image with the IT buyers that they really need to reconnect with — namely the sysadmins and network architects looking to cut costs and avoid the bloat that is Windows Server.

There are certainly no losers when it comes to this announcement, and more open-source software being certified — legitimized even — is always a good thing.

Source

MAAS Effect: Canonical dives into bare metal cluster provisioning

As every system administrator knows, remaining nimble with virtual and hardware resources is an absolute must when it comes to managing cloud infrastructure. Something that is often easier said than done because of the wide, dynamic array of tasks that such a network needs to accomplish. If you have ever worked to deploy Hadoop or OpenStack clusters, you’ve most likely experienced the mind-numbing frustration of having to micromanage bare-metal resources to stay on top of the myriad number of hardware intensive tasks that need to be accomplished. Canonical has felt your pain and has decided to do something about it by developing a tool called Metal as a Service or MAAS for short.

To describe MAAS in a simple way, it’s a new tool that allows you to easily provision actual hardware resources on the fly to different tasks. Say you need twenty clusters or so to allow Hadoop to aggregate data for a certain period of time, but then need to reallocate that power elsewhere when that process is finished, MAAS allows you to do that with just a few clicks of the mouse instead of a long administration process. In essence, making it just as easy to provision real-world resources as it is to do so with virtualized nodes. Think of it as enabling you to consider physical servers as cloud-like resources. Pretty exciting stuff.

In addition to the ease with which you will be able to deploy hardware, MAAS will also automate grunt work such as firmware updates, performance evaluations, and other various tests and report back to you. Add in the fact that it’s fully compatible with Ubuntu’s JuJu charms, and you have a powerful tool that has a rich API which you can write small applications to take care of the more mundane tasks automatically. Suitable for the cloud-engineering novice or seasoned veteran, Canonical has developed this tool to help cement its place as one of the top pieces of software for cloud infrastructure.

Personally, I am excited about the inclusion of this tool in the 12.04 LTS release of Ubuntu Server because of the way it allows you to change the way you look at hardware clusters. Computing power has always been a commodity, but the barriers to opening the gateway to it as a resource have always been tedious in my mind. Virtualized hardware is faster and easier to deploy, but has a significant drawback when it comes to such power hungry applications like those mentioned above. By enabling a macro view of the resources you have at hand and taking out the really tedious tasks out of your workflow, Canonical has created a way to allow you to become a broker rather than just a consumer. For example, with Amazon AWS or Microsoft Azure you are the consumer, plain and simple. You tell them what you need in the way of power and they provide it. With MAAS, companies can now leverage the hardware they already have access to for internal needs as well as farm out excess cycles to other parties that would be willing to pay for it on an as-needed basis. The practicality of the tool appeals to me in this way.

If you want to play with MAAS right now, you can download a beta of Ubuntu Server 12.04 to install and mess around with. The final product will be delivered on April 26, so the daily builds that are available now should be pretty close to production barring any major changes or bugs that will be found. It will be interesting to see what the MAAS effect (see what I did there?) will be on the cloud industry as a whole.

Source