STE VE CAS­SIDY

PC Pro - - November 2017 Issue 277 - cas­sidy@well.com

In an un­likely first, and prob­a­ble last, Steve chan­nels the wis­dom of Don­ald Rums­field be­fore head­ing off to meet DAFNI – and ask­ing fire­wall ven­dors to break their prom­ises.

It’s dif­fi­cult to ad­mit that you’re a fan of Don­ald Rums­feld. Most peo­ple re­mem­ber him as a war­mon­ger, but it’s his com­ment about “un­known un­knowns” and the na­ture of knowl­edge that will al­ways stick in my mind. He even called his mem­oirs “Known and Un­known”, a nod to the men­tal tongue-twister he came out with to de­scribe the hunt for weapons of mass de­struc­tion in the de­feated state of Iraq.

To me, that ap­pre­ci­a­tion of the di­vi­sion of ev­ery­thing in the world into things you can un­der­stand and af­fect, and things you can’t, is an ad­mis­sion of hu­mil­ity. I re­alise that a col­umn in PC Pro isn’t where you’d nor­mally come for anal­y­sis of late 20th-cen­tury po­lit­i­cal fig­ures, but there is a link, I prom­ise. This month, I’m look­ing at a part of the an­a­lyt­ics busi­ness, hav­ing just walked through its hot breath, counted its cores in their tens of thou­sands, and tried to make sense of the prom­ises I was hear­ing.

This is part of my in­creas­ing sense of un­ease and there­fore deeper in­ves­ti­ga­tion of the prom­ises made on be­half of ar­ti­fi­cial in­tel­li­gence. Long-term read­ers might ex­pect me to trot out my early ca­reer ex­pe­ri­ences within this field, as an ap­ple-cheeked youth at­tend­ing the meet­ings of the fi­nance in­dus­try club within the Alvey Direc­torate – a 1980s govern­ment project to ap­praise the scale of the threat posed by al­leged “fifth­gen­er­a­tion” Ja­panese ex­pert sys­tems. Not only was the scale of that threat over­es­ti­mated, across all par­tic­i­pat­ing in­dus­tries and sec­tors, but many of the clubs couldn’t get much in­ter­est in the sys­tems they pro­duced.

Against the back­ground of that project, most of to­day’s press re­leases mak­ing claims about AI look a bit thin. The Alvey Direc­torate clubs worked on In­tel 80286 PCs, a good five or seven gen­er­a­tions back from the mod­ern day: the idea that im­mense horse­power is re­quired to de­liver AI is hard to jus­tify when the process of mak­ing de­ci­sions within the AI can be fit­ted into some­thing as small and slow as a 286 CPU.

I’ve al­ready man­aged to insert my­self into the in­vite stream for a lot of su­per­com­put­ing projects and or­gan­i­sa­tions. Quite apart from the un­lim­ited nerd ap­peal of data cen­tres at the up­per end of the bud­get scale, I’m in­trigued by the com­par­i­son be­tween what’s con­sid­ered to be a “desk­top” project, a “lap­top” project, a “cloud” project, and then a “su­per­com­puter” project.

For com­par­i­son of a prob­lem (or, if you want to be busi­ness-like about it, of a bud­get) across fields that ap­pear to be us­ing the same re­sources, there’s noth­ing bet­ter than the process of run­ning anal­y­sis of chunks of data. The over­all lessons re­main the same across all the in­dus­tries that are now pro­duc­ing ever more data, ever more te­diously, with­out let-up. Sud­denly, peo­ple who saw their fu­ture in sewage man­age­ment are hav­ing to re-learn lessons from com­puter sci­ence as prac­ticed in the late 1960s.

So, even be­fore I fig­ured out where I’d be vis­it­ing, the in­vite to look at DAFNI from the STFC at RAL slot­ted neatly into one of my big in­ter­ests for this year. That’s the Sci­ence and Tech­nol­ogy Fa­cil­i­ties Coun­cil, whose

op­er­a­tions are at Ruther­ford Ap­ple­ton Lab­o­ra­tory, known to an older gen­er­a­tion as Har­well. DAFNI stands for Data and An­a­lyt­ics Fa­cil­ity for Na­tional In­fra­struc­ture – a com­bi­na­tion of hard­ware, soft­ware and skilled as­sis­tance that al­lows re­searchers to take their data an­a­lyt­ics prob­lem and give it a shot in the arm.

And it’s quite a shot. Go­ing round RAL’s data suite soon af­ter vis­it­ing the Swiss Su­per­com­put­ing Cen­tre ( see

is­sue 276, p120) was a fas­ci­nat­ing com­par­i­son. The Swiss like large, wa­ter-cooled stand­alone ma­chines hooked up to rather smaller in­dus­try­s­tan­dard, di­verse pools of stor­age de­vices. The Bri­tish are al­most the other way, with a vast ar­ray of com­mod­ity, gen­eral-pur­pose servers (mostly Dell, from what I saw) de­pen­dent on a mas­sive de­ploy­ment of cloud hy­per­vi­sors and man­age­ment tools (NAGIOS fea­tured heav­ily).

This is hooked up to a highly spe­cific stor­age pool, which lifts their abil­ity to load and un­load datasets from dif­fer­ent dis­ci­plines as cloud de­mand suits. While the Swiss talked in terms of megawatts of ca­pac­ity, the English had dif­fer­ent bench­marks. They keep 18 petabytes avail­able, and nor­mally move about 3 petabytes a week. I saw man­age­ment screens show­ing 23,000 cores spread across the es­tate of servers, and a wee box that said the av­er­age CPU load was 77% – al­though I didn’t see any in­for­ma­tion that might link those two statis­tics.

For any­one whose head is al­ready spin­ning, I re­fer you to two pic­tures. One is of a handy chart ( see left) of the rel­e­vant pre­fixes for scales of data, left on one of the cab­i­net doors in the data cen­tre. There were many of th­ese cheery signs on all sorts of top­ics, be­cause they’d just had a vis­it­ing group come through and signs make a bet­ter im­pres­sion than the usual ranks of whirring ma­chines.

The other pic­ture is a bit of a sharp in­take of breath for band­width geeks ( see above right). It’s ac­tu­ally the main ar­chi­tec­ture cab­i­net, where all those Dell Pow­erEdges are linked up through 40Gbits/sec fi­bre switches to talk to each other and to the whole world. The whole world ar­rives on a lit­tle clus­ter of four fi­bres, more or less cen­tre-bot­tom in my pic­ture: that’s their 40Gbit/sec link to the rest of JANET, the UK’s in­tra-aca­demic net­work. All the other fi­bres in the pic­ture are link­ing servers with each other and with stor­age. I was go­ing to take more pic­tures of the racks them­selves, but the fact is th­ese are Dell Pow­erEdges (looked a bit like R Series 1Us to my eye) and you can see those any­where.

The im­plicit dis­agree­ment be­tween the two su­per­com­puter houses over which ar­chi­tec­ture suits best isn’t eas­ily re­solved. Both are re­cip­i­ents of raw data dumps from CERN, so both have a guar­an­teed back­ground work­load that’s al­ready oner­ous. How­ever, the Swiss seem happy to par­cel out the work­loads by al­lo­cat­ing not just a core pool, but also an OS to a par­tic­u­lar re­quire­ment. The Brits, by con­trast, are look­ing at the en­tire in­stalled base of servers as one vast fabric of com­pu­ta­tion, and peo­ple may ask for largely ar­bi­trar­ily cho­sen slices of that pool to do work on their par­tic­u­lar re­quire­ment.

It’s a mea­sure of the na­ture of the Har­well Cam­pus that DAFNI’s work is ac­tu­ally a bit less glam­orous, if any­thing, than that done by the Di­a­mond Light Source or any of an­other dozen UK res­i­dent re­search projects. Driv­ing in through the an­cient maze of air­field roads, pass­ing by build­ings from ev­ery decade since the site was taken over, you half­ex­pect to see M tak­ing Bond round an au­t­o­gyro, or Austin Pow­ers hav­ing the Union Jack on his Jag touched in.

Let’s stick to DAFNI, though. The trail of logic from its an­nounce­ment (read it at pcpro.link/277dafni) is that an­swer­ing tough ques­tions about sys­tems is best done by stop­ping work­ers in the var­i­ous fields from de­vel­op­ing their own mea­sure­ments, al­go­rithms and re­port­ing. In­stead, it’s bet­ter to get your data to be DAFNI-ready, and then bench­mark not just your par­tic­u­lar data sources, but your en­tire seg­ment’s over­all disas­ter and ex­treme event re­silience, by sub­mit­ting that data to a stan­dard­ised and cen­tralised ap­praisal.

This isn’t quite what I was ex­pect­ing. I’m rea­son­ably au fait with the way that large ur­ban projects are mod­elled, at least when it comes to their fi­nan­cial re­quire­ments, but clearly here the net was be­ing thrown far wider. For one thing, the as­ser­tion is that smart cities and a sen­sor-ori­en­tated de­sign and anal­y­sis in many quite nar­row fields of re­search are all uni­formly ap­prais­able us­ing the same ba­sic chunks of logic. For an­other, the DAFNI team threw out a ca­sual aside that made me want to stand up and cheer. They said that quite a lot of re­searchers around the sub­ject of in­fra­struc­ture do their work on a sin­gle desk­top PC.

Sel­dom have I found a snip­pet of val­i­da­tion so sat­is­fy­ing. When writ­ing about such big projects, I al­ways try to re­late the chal­lenges and the lessons back to phe­nom­ena you can ex­pe­ri­ence on your own ma­chine. Here’s a pre-baked com­mu­nity of peo­ple who are be­ing ap­proached be­cause the work they need done can be scaled up, from that one hum­ble ma­chine to an ar­ray of CPUs counted in the tens of thou­sands, run­ning at about 1.2 megawatts.

“I’m rea­son­ably au fait with the way large ur­ban projects are mod­elled, but clearly here the net was be­ing thrown far wider”

Oddly, the DAFNI team was slightly shy about how many of its ap­pli­cants were in this cat­e­gory, but I think this is par for the course. My own ex­pe­ri­ences with the emo­tional con­se­quences of a sud­den per­for­mance boost is sim­i­lar. I once nudged a re­searcher to give up on his Pen­tium D HP work­sta­tion – run­ning beau­ti­fully but by then eight years old – and have a go with a Ne­halem-series Xeon. His run times went from 15 min­utes per sce­nario to no de­tectable de­lay. In­cred­i­bly, he didn’t do a vic­tory lap of the of­fice when this re­sult came in: he hid it away, still us­ing the hot old Pen­tium D as his email and web-surf­ing ma­chine.

The same reaction came much ear­lier in my ca­reer, when we took a chunk of BA­SIC that ran overnight to pro­duce a sin­gle out­put num­ber on the stan­dard IBM PC, and adapted it to com­pile on a some­what larger VAX clus­ter mini-com­puter. Run­times were mostly within the time it takes to say “one two three GO”; un­for­tu­nately, there were up to 60 other users on the VAX at the same time. So the next meet­ing at the Trea­sury on this sub­ject was en­light­ened not by 20 or so runs off a wheez­ing IBM PC, but by well over 2,000 cour­tesy of the VAX. Again, sheep­ish­ness was the pre­dom­i­nant reaction.

The burn­ing ques­tion posed by the head­line of DAFNI’s in­tro­duc­tory piece is, does more horse­power equate to bet­ter re­silience to ex­treme events? I think the an­swer in this era of in­tol­er­ance for ex­per­tise has to be frank and trans­par­ent: “not di­rectly”. There will be a bu­reau­cratic ben­e­fit, that a type of model bench­mark­ing be­comes pos­si­ble to give re­searchers some idea of whether they’re un­der (or over) achiev­ing when it comes to the com­plete­ness of their model, or the com­par­i­son with other mod­els.

It’s a long road from a model of a city’s wa­ter sup­ply and sew­er­age sys­tem, to a plan that keeps them sep­a­rate dur­ing cat­a­strophic flood­ing. Like­wise, a view of the en­tire do­mes­tic UK in­ter­net may have cer­tain philo­soph­i­cal sim­i­lar­i­ties to the wa­ter/sewage de­sign – but that doesn’t mean that the weak­nesses pop­ping out of the model are easy, ob­vi­ous or even cheap to fix.

Which is why I al­ways bear Rums­feld’s quote in mind when it comes to ex­treme events and ex­treme com­put­ing. It isn’t the known knowns that are the prob­lem, nor even the known un­knowns. Those can be put in the model and given some num­bers. It’s the un­known un­knowns that play the largest part in de­ter­min­ing the ex­treme sta­tus of an event, and no amount of com­puter power is go­ing to help with those.

Prom­ises in se­cu­rity

An­other visit this month was to the new City of Lon­don of­fices of Ju­niper, the fire­wall and net­work­ing com­pany. Ju­niper has been en­croach­ing on the home turf of Cisco for ten to 15 years now: a fight up in the en­ter­prise net­work bor­der se­cu­rity world, which us hum­ble toil­ers in the small-to-medium busi­ness sec­tor don’t re­ally have to lis­ten to much.

Ex­cept that ven­dor-to-ven­dor isn’t the only fight th­ese guys are in. They have the chal­lenge of be­ing the per­ceived front line of de­fence against each hack at­tack that comes along, which en­tails a cer­tain econ­omy with the truth. If you’re a fire­wall OS ven­dor, then your cus­tomers will di­vide into con­stituen­cies when it comes to the an­nounce­ment of a new hole. There will al­ways be those who fly into an in­stan­ta­neous panic; those who im­me­di­ately re­place your equip­ment with that of your main com­peti­tor; those who sit tight; and those who ut­terly ig­nore your an­nounce­ment. It’s this spread of re­sponses that makes the whole topic of se­cu­rity so dead­pan, so cau­tiously worded that the nec­es­sary im­pact just doesn’t seem avail­able.

The prob­lem I found Ju­niper to un­der­stand the best, though, is the mat­ter of the com­plete in­dus­try right-turn. Many fire­wall ven­dors make prom­ises; they have to – it’s the main method by which they can demon­strate their abil­ity to com­pete. The prob­lem is that the se­cu­rity threats have no obli­ga­tion to keep their at­tacks within the terms of ref­er­ence of a prom­ise made by their op­po­nents.

In short, this pro­duces a series of state­ments from the ven­dor that have a shelf life of about half a year. Yet cus­tomers still make their se­cu­rity bod’s life a mis­ery, by point­ing out that last year the hot pro­tec­tion tech was all about un­so­licited, pos­si­bly half­com­plete IP pack­ets bash­ing on the fire­wall from out­side. Here’s the sheet of pa­per, says the CEO. You told me be­fore Christ­mas that prod­uct X was the bees knees and that we’d be okay. And now you want some­thing else…

This is the tough part of com­mu­ni­cat­ing how much of a par­a­digm shift this busi­ness has been through. For one ex­am­ple, the Ju­niper spokes­peo­ple said as an aside that they were now hav­ing to cope with the gang­sters be­ing rich enough and well enough pro­tected that they could af­ford to buy ex­am­ple fire­walls at list prices, and take out sup­port con­tracts, and then bash on those ma­chines at their leisure in their labs, look­ing for ways in. So the fire­wall soft­ware has to take a leaf out of the Volk­swa­gen book and have ex­tra code that fig­ures out when it’s be­ing tested, and whether to call home and cry for help.

Or call else­where. A long con­ver­sa­tion about the dif­fi­culty of siz­ing a bit of kit to do traf­fic anal­y­sis for ran­somware ended up mak­ing ref­er­ence to ac­cess to IBM Wat­son: buy Ju­niper’s smart anal­y­sis suite and start ask­ing it ques­tions, and what you are ac­tu­ally talk­ing to is a net­work-trained va­ri­ety of Wat­son. There’s a shift in the ba­sis of func­tion for you, right there. And Ju­niper’s own reaction to this is symp­to­matic of the prob­lem – it’s at the same time pleased to be able to do such a thing, and some­what em­bar­rassed that the ear­lier it­er­a­tions of its prod­uct line let the bad guys ad­vance so far that it’s be­come nec­es­sary.

I think the en­tire in­dus­try will have to draw a line un­der all those ear­lier prom­ises, just to make the con­ver­sa­tions eas­ier and clearer for the much larger au­di­ence that must now pay at­ten­tion. Jar­gon and hype don’t se­cure your bank ac­count, your per­sonal data or your com­mu­ni­ca­tions.

“Fire­wall ven­dors make prom­ises; they have to – it’s the main method by which they can demon­strate their abil­ity to com­pete”

@star­dot­pro

Steve is a con­sul­tant who spe­cialises in net­works, cloud, HR and up­set­ting the cor­po­rate ap­ple cart

BE­LOW Use­ful in­for­ma­tion to have in a data cen­tre – if your head is in a spin...

ABOVE The whole world ar­rives on a clus­ter of four fi­bres at the cen­tre bot­tom of the pic­ture

ABOVE Net­work­ing com­pany Ju­niper is do­ing well in th­ese chal­leng­ing times

Newspapers in English

Newspapers from UK

© PressReader. All rights reserved.