Intel Announces Avoton Server Architecture and Software Defined Services Effort
MojoKid writes "Intel unveiled a number of new data center initiatives this week as part of its broad product strategy to redefine some of its market goals. Santa Clara has begun focusing on finding ways to expand the utility of its low power Atom servers, including the upcoming Avoton Atom products, which are based on the 22nm Bay Trail architecture. Intel isn't just pushing Avoton as as low-power solution that'll compete with products from ARM and AMD, but as the linchpin of a system for software defined networking and software defined storage capabilities. In a typical network, a switch is programmed to send arriving traffic to a particular location. Both the control plane (where traffic goes) and the data plane (the hardware responsible for actually moving the bits) are implemented in hardware and duplicated in every switch. Software defined networking replaces this by using software to manage traffic and monitoring it from a central controller. Intel is moving towards such a model and talking it up as an option because it moves control away from specialized hardware baked into expensive routers made by people that aren't Intel, and towards centralized technology Intel can bake into the CPU itself."
It'd be nice if Intel can build a function to send the data immediately to NSA, yes?
Intel has the POWER !!
AMD ?? Not so much !! Really, AMD !! Come on !! If you can't play with the big boys get out !! Get out now !!
How can it be software-defined if it's baked into the CPU?
avorton : avorton m (plural avortons)
abortion (fruit/produce that doesn’t come to maturity)
Who are the morons spreading "software-defined" bullshit when there already is a common, well-understood word that perfectly describes the feature?
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
We loop back to Service As A Service.
Now that's the real deal!
Whoever figures that one out is gonna make a bundle.
Seriously, are these people stupid at Intel or haven't they learned anything in the past 20 some years the Net has been around about software and why it is incredibly bad to centralize that sort of control and power in a single entity in infrastructure.
Let alone on a computer network?
There is no possible use for something like this unless you want to centralize power and control over the entire network mesh from one location.
Bad for business, bad for citizens in every country who deploy it, just plain bad idea. I might be inclined to give it a serious thought if I was Alice in Wonderland and could rely on the Chesire Cat to keep things on the up and up.
But you have to be kidding me? We have governments that would destroy the entire internet with this crap as it is right now if they had that sort of control.
Seriously, don't buy that crap and do not contribute to such a open source project.
-Hack
Got Geometrodynamics? Awe, too hard to figure out? Too bad.
SDN can suck it. As a guy that lives in the trenches, between lags, mstp, vlan routing, vrrp/hsrp, trill, and now big routing protocols showing up in the datacenter (think ospf/bgp) and a motley crew of various other l2 and up protocols, we have enough decentralized means for corralling bits to their regularly scheduled programs. SDN is just big content's wet dream, or network odm's looking to get in on the 'app' craze.
'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
adding 10GBE and an raid card / pcie based ssd can eat up all of pcie lains fast. Even more if they try to jam an video chip and TB on there as well.
No QPU kills more then 1 socket. Also not listed is the number of ram channels.
When I think about management problems we have today they are almost entirely caused by unaddressed suckage in various layers of existing stack. Rather than fixing underlying problem people insist on adding new layers of complexity to workaround them.
It started with virtualization. Operating systems lacked the management and isolation features users needed. Rather than fixing the operating system just virtualize everything and run a whole shitload of images on one machine. Now instead of one system image to maintain you have a shitton of them and you have wasted great sums of storage, memory, management and compute resources all because you were too lazy to ask vendors to solve your origional problem.
Next we have capwap/openflow complex specifications intended to normalize configuration of all your network things. A lot of this is caused by IT chasing architectural fallacies such as "network security" and "redundancy". Layers upon layers of IDS, firewall and god knows what to "secure the network". The very concept of things like "internal network" or load balancers used for application redundancy are flawed, stupid and dangerous. What part of "insider threat" do people not understand?
Routers should be stupid devices which punt packets between interfaces. The error is placing complexity where it does not belong and then go have to go mask the repercussions of a poor choice with SDN cuz otherwise it is all just too hard to manage.
What would happen if for example rather than an expensive load balancer for a web farm browsers simply implemented a hueristic to pull multiple IPs out of DNS and use a delay timer to make make multiple connection attempts with term memory of failed requests and RTT feedback. You could effectivly mask a failure in the string group with little to no noticable delay until the failed system can be repaired or yanked from DNS.
The most detremental error I see repeated constantly is this notion the data tier, the network or the operating system is somehow responsible for the lack of scalability or availability of an application. This is fundementally bullshit. Systems must be DESIGNED to scale. Smoke and magic by a vendor only delay or mask underlying problems. We need smarter software not software defined gimmicks.
So, here's some random, somewhat connected ideas. This is a long winded post, but please bear with me. First, take a look look at the buzzwords, and you can tell where the money will be flowing. Several years ago, the big thing was "Green" right? Then came "Big Data", and the last 2 or 3 years have been all "Cloud". Now if you've been paying attention, this year's buzzword is "Software Defined $TECHNOLOGY", which of course was kicked off with "Software Defined Networking" (SDN).
This is my notion of what we'll be seeing tons and tons of this year and for the next couple of years until the Next Big Thing hits, and if you move fast, you've got a great chance to get in on the ground floor, so to speak, and sell a shit-ton of product to big, dumb enterprise. Here's the premise: Think of a general area of technology, and try to apply the VMware approach to it; that is, decouple, generalize, pool resources, and rename your tech "Software Defined $TECHNOLOGY". Gold mine.
So, among other players and products, VMware took x86 virtualization from an obscure tech to an every day item that most of us use on a daily basis, whether you're an SA, developer, whatever. If you work in a medium to large shop, you're using VMware. Great (but vastly overrated) product, great timing, these guys really shook things up. So take that same method, that shim (hypervisor) that slipped between the hardware and the OS allowing us to do all kinds of cool stuff: consolidation, live workload migrations, live storage migrations. Take that methodology, that concept, and apply it do different parts of the stack.
Storage: this has been going on in the mid-range and enterprise storage space for several years already. In the past we'd have an array w/hundreds of drives which we'd group into RAID groups, the type and sizes dictated by workload (space, IOP requirements, etc), then from our RAID groups we'd carve the LUNs and present them to the servers. The only issues with this were those of flexibility after the LUNs were presented and what do you know, you need more space, IO, whatever, then you need to do a LUN migration to bigger/faster. Or a more common case is the people asking for disk don't know what they really need, so they way overshoot the space/IO req's and you deliver way more than they end up using, and you just wasted tons of premium disk.
So the 'fix' the storage vendors came up with is the first small step into virtualizing storage: instead of rigid RAID groups and having to have a somewhat knowledgeable storage guy on staff, the storage vendors came up with storage pools. You take a hundred or a few hundred spindles and toss 'em into the pool, and carve LUNs from there. It's like this monstrous RAID group that can absorb 20,000 IOPs (or some crazy number depending on how you slice and dice your array.) Instead of RAID groups dedicated to each application, you now have all of your low-end and mid range applications sharing the same storage pool. Sort of how like you can run 100 OS instances on a small VMware setup. Instead of buying 100 servers, you buy 4 or 5 and dump all of those Windows boxes that that average less than 1% utilization into the VMware cluster, and save a mint on hardware and data center rack space, right? Same idea w/the storage pools. The only problem is you're still dealing with the same vendors and buying tons of overpriced spindles; not as many, but still a lot and you're paying dearly for it.
So the next step is to get away from the arrays that cost $100k's/$megabucks, mix in some scale out mojo (GlusterFS, whatever), add a dash of pooling, use off the shelf servers stuffed w/cheap disk perhaps fronted with some SSD/flash, and voila: "Software Defined Storage". You heard it here first! Or maybe not, you probably thought of this as well. (I was daydreaming this stuff a while ago, and the next day went to a local VMware conference, and no shit, an EMC guy had this same idea and terminology on one of his PowerPoint slides.)
OK, so that's storage. What else can w
As a Finn the name is about to be twisted pun here.
Just two most obvious,
s/Av/Aiv/g -> brainless
s/Av/Arv/g -> worthless
and I'm sure these aren't worst someone will come out.
Did he say .. "Voltron"
Oh, that's right.....the old phone system that we have largely replaced with DISTRIBUTED routing & switching infrastructure. Funny how old ideas come around as "new" ideas.
How the hell did the discussion suddenly get side tracked into blaming Intel and the hardware manufacturers for creating software security issues? But lately any post about hardware that is not 100 percent Microsoft friendly seems to get slagged by idiots.
The highest rated posts are essentially rants, not a whisper about why going along with Intel and essentially HP's modular hardware and software initiative has the potential to reduce costs and make securing and maintaining complex diverse networks easier.
SoCs in servers with a flexible software setup are what is coming guys the days of putting add on cards and software drivers for servers is limited. WHAT YOU do with the system and how you run it is the security system not THE OS or the hardware. Essentially Intel and many others are telling Microsoft to take a flying f++k with the security on chip garbage. AND IT IS ABOUT FRIGGIN' TIME
Within ten years it will be standard that plug in SoCs cards populate servers. The bandwidth problems are no longer an issue.
Intel and HP have it right this time moving away from the old mind set that you can only configure a server selling only proprietary closed source software drivers and closed operating systems that you pay extra depending on node scale size. Linux is poised to kick Microsoft's royal ass this time around. And it is largely due to what Microsoft has done to the industry by insisting on a piece of the processor number pie. Not to mention bullying the shit out of everybody in the consumer market with their hair brained locked boot loaders and data execution locks.
This is why Intel and HP are partnering with everybody but Microsoft on these chips and systems. Having to run closed MICROSOFT code and closed driver binaries has been the security problem with 64 bit servers and anyone with a brain realizes this.
This message was not sent from an iPhone because Peter Sellers really was a deviated prevert without a dime for the call