Afvejninger mellem On-Premise og On-Cloud Design

Genudgivet af Platon

Abonnenter: 0

Eksperter ved bordet: Semiconductor Engineering satte sig ned og diskuterede, hvordan og hvorfor virksomheder opdeler arbejde on-premise og i skyen, og hvad man skal være opmærksom på, med Philip Steinke, fellow, CAD-infrastruktur og fysisk design på AMD; Mahesh Turaga, vicepræsident for forretningsudvikling for cloud kl Cadence Design Systems; Richard Ho, vicepræsident hardwareteknik hos Lightmatter; Craig Johnson, vicepræsident cloud-løsninger hos Siemens Digital Industries Software; og Rob Aitken, stipendiat ved Synopsys. Det følgende er uddrag af den samtale, som blev holdt foran et levende publikum på Design Automation Conference. Første del af denne diskussion er link..

SE: Med så meget på spil i chipdesign i dag, hvordan opnår du det bedste ROI med cloud-ressourcer?

Steinke: Da vi valgte arbejdsgange til cloud-aktivering, startede vi med at se på dataene. Hvilke har et overskueligt sæt data, der kan indkapsles, flyttes til et cloud-hostet datacenter for at udføre en form for beregning og derefter få en rimelig mængde resultater, der kommer tilbage? Et af de områder, vi fokuserede på, var frontend-verifikation. Mit foretrukne flow der involverer at holde vores builds on-premise, samle selve modellen sammen med teststimulusen og sende den ud for at udføre den faktiske simuleringsaktivitet på cloud compute. Den anden klasse af arbejdsbelastninger, som vi har aktiveret skyen for, er fuld-chip-verifikationsarbejdsbelastninger, fuld-chip-signoff-kørsler for statisk timing, fysisk verifikation og strøm - primært fordi du i et sted-og-rute-miljø kommer ind i en regelmæssig kadence af daglige ECO'er eller almindelige ECO'er, der sker og foretager ændringer, og der er allerede et datastyringsopsætning, hvor udgivelser af designet udføres. Så vi er i stand til at sætte kroge ind i den frigivelsesmekanisme, ikke bare for at sætte den i en slags lokal udgivelsesvolumen i vores eget datacenter, men for derefter at skubbe disse data til et cloud-datacenter, der er blevet udvalgt til at udføre disse job. En af bekymringerne ved den store arbejdsbyrde er, at hvis du allerede har din fusionerede Oasis, eller hvis du har samlet alle de specifikationer for dit design, som du vil køre statisk timing på, er det en betydelig del af data, der skal skiftes. alt på en gang. Men ved at opdatere udgivelsesmetoden på blokniveau, så drypper de ind, efterhånden som hver blok frigives i løbet af dagen. På den måde kan du starte det cloud-hostede analysejob med fuld chip med lavere latenstid. Den største udfordring, jeg har set, er adgang til gode cloud-VM'er med nok hukommelse til at køre de store opgaver. Det er endnu et område, som vi fortsætter med at presse vores cloud-partnere til at tilbyde - løsninger med masser af RAM, som chipdesignvirksomheder kan bruge.

SE: Hvilke råd kan du give om at bestemme, hvornår en arbejdsbyrde skal udføres på forhånd versus på cloud?

Aitken: Der er en interessant dynamik, vi ser netop i repræsentanterne i dette panel, fordi den måde, Richard kan gribe det an på, og den måde, Phil kan gribe det an på, vil være anderledes. Man er meget fokuseret på et design, der bevæger sig gennem tinder og dale i forhold til behov. Hos AMD er der formentlig masser af designs i gang hele tiden, så der er en indledende indsats i forhold til, hvad det er, de forsøger at gøre. Hvilken infrastruktur giver mening, hvis du forsøger at komme til en verden, hvor du skal lave alt dit design i skyen, og du bare helst ikke vil have et on-prem datacenter overhovedet? Den måde, du griber det an på, vil være anderledes, end hvis du bruger skyen som backup og udvidelseskapacitet til en massiv infrastruktur, du allerede har.

SE: Hvordan beslutter du dig rent praktisk?

Et host: Du ser på dataene. Hvor meget data har du? Hvor meget data vil du generere? Og hvad skal du have tilbage? Det vigtigste for at få det til at lykkes er, at den information, du vil have tilbage fra skyen. On-prem skal være minimal, så det er kun rapporterne og resultaterne af dine regressioner, der skal dukke op. Vores build er faktisk på vores lille on-prem. Vi sender det op og kører vores simuleringer derude, og vi laver vores egen dækningsanalyse. Så sender vi resultaterne tilbage, og det er meget lille, og det er godt. Back-end er anderledes. På den fysiske design del, sender du designet derud, du vil have det til at forblive på skyen så længe du kan, fordi disse databaser er enorme, og du virkelig ikke ønsker, at det kommer tilbage overhovedet. På det tidspunkt er det infrastruktur som en service. Du skal bare have dine folk til at logge ind i skyen og lave alt det fysiske design deroppe, indtil du får GDS. Der er det tingene inde i maskinen - hvor meget hukommelse kan du få? Det er en af begrænserne. Det er faktisk meget dyrt at have meget store virtuelle maskiner i skyen. Ganske ofte er det billigere at købe din egen. Vi har ikke talt om omkostninger. Omkostningerne ved cloud er ikke, hvad folk tror. Det er ret højt. Det er mere end on-prem ret ofte, så du skal balancere det for at få fordelen ved at være fleksibel og få adgang til de store hukommelsesressourcer. Og måden det ser ud på vil være meget individuelt for hver kunde.

Johnson: Dette spørgsmål relaterer virkelig til ROI af at gøre det. Det afhænger af, hvad du forsøger at opnå som bruger af miljøet, og det er en del af udfordringen. Hver virksomhed laver sin egen beregning baseret på deres strategi for at finde ud af, hvad de vil gøre i skyen, og hvor aggressivt de er villige til at bruge for at høste denne fordel. Det andet element er, at det afkast, du måler, er anderledes end ejeromkostningerne. Vi har tendens til at være bedre til at lave total-cost-of-ownership-analyser end "R"-delen af ROI, som derefter skal bringe mere immaterielle faktorer i spil, gennemløbstid og time-to-market-fordel.

Aitken: Selv med noget så simpelt som latency, når du kører et værktøj, og responstiden er: 'Jeg flyttede musen, og et stykke tid senere sker der noget', kan det være meget frustrerende.

Turaga: Historisk set, hvis vi ser på ROI for cloud, er der tre klasser af værktøjer, der kan udnytte cloud meget effektivt. Først er designorganisationen, designgentagelser, regressioner med verifikation. For det andet er der langvarige simuleringer med store beregningsbelastninger, og de kan skaleres meget godt for at drage fordel af beregningsalgoritmerne i forskellige tilfælde. For det tredje er den interaktive type, som de værktøjer, der kræver latens og også kræver en masse vækst i samarbejdet. Det er de tre kategorier af værktøjer, der får det bedste ROI fra skyen. Og igen, afhængigt af hver kundesituation, afhænger det af, hvilket værktøj de vil starte i skyen. Nogle af vores kunder startede med verifikation, men det afhænger af din specifikke kundesituation.

SE: For cloud-brugerne, hvordan nåede du frem til beslutningerne for din cloud-brugsmodel?

Steinke: Vi har været rundt et stykke tid. Vi havde allerede et ret stort datacenter, så vi behøvede ikke at gå all-in i begyndelsen. Vi søgte at udvide det, vi har, med det, skyen har at tilbyde. Vores on-prem datacenter leverer fortsat en enorm mængde af vores computerkapacitet. Projekter kommer og går, og der sker uventede ting; at være i stand til at skabe denne fleksibilitet og have flere beregningskilder, som vi kan trække fra, er en fordel, som vi ønskede at hoppe på. Det har været en stor del af vores motivation for cloud, og hvorfor vi gik den vej. Vi havde allerede den forhåndsinvestering, så det var noget, vi søgte at udvide og bygge videre på.

Et host: Jeg kan svare på dette fra to perspektiver. Det første perspektiv er, at før jeg var hos Lightmatter, arbejdede jeg hos Google på TPU og på infrastrukturteamet, og vi brugte også cloud der. Svaret der er anderledes end svaret hos Lightmatter. Et af de spørgsmål, du skal stille dig selv, er, om du vil have dit repo (repository) on-prem eller i skyen. Hos en virksomhed som Google, og formentlig AMD, vil de have deres repo on-prem. De føler sig mere sikre, de føler, at det er mere i deres kontrol. Hos et mindre firma som Lightmatter er jeg ikke nødvendigvis ligeglad. Jeg var fortrolig med sikkerheden i skyen, så jeg kan have en repo i skyen. Og i den mindre sammenhæng betyder det at have repo i skyen, at vi næsten bruger cloud som en fuld infrastruktur. Det er det samme som min on-prem. Det er den første bekymring. Den anden bekymring er arv. Nogle virksomheder har legacy, og når du forsøger at flytte fra legacy til en cloud-baseret løsning, skal du virkelig forstå, hvad du får, hvilket taler til målet med dette panel. Vi forsøger at pege på, hvor du opnår en fordel i forhold til fleksibilitet, i forhold til at kunne have nyere maskiner osv. Det, der virkelig tæller, er nogle af de arbejdsbelastninger, hvor du har mange parallelle kørsler i gang. Du vil administrere et stort sæt af servere og kørende job, og det er der, du skal gå i skyen. Det kan du få din arbejdsbyrde til at udnytte. Så kommer man tilbage til dataflow, hvor man har en begrænsning, så skal man tage en beslutning. Vi tog beslutningen om at have repo for det fysiske design i skyen, men andre virksomheder har ikke. Jeg ved, at virksomhederne har flere. De har lavet en masse fysisk design stadig on-prem, fordi de har brug for meget lagerplads og ikke har brug for så mange maskiner. Så du er nødt til at se på hver af de sager og træffe en beslutning baseret på din situation.

Turaga: Mange af vores små til mellemstore kundestartups ønsker ikke repoen på stedet. De har ikke ældre datacenterproblemer, så de omfavner virkelig cloud fuldt ud. Nogle af de større virksomheder, der har enorm on-prem-infrastruktur, er allerede ved at gå over til en hybridmodel.

SE: Med det næsten forbløffende antal forekomsttyper, der er tilgængelige i skyen fra forskellige leverandører, oven i licensomkostninger, som endnu ikke er optimeret til skyen, hvordan kan brugere forbedre den måde, de vælger den rigtige form for forekomst til at udføre deres job på?

Johnson: Dette er en af de grundlæggende ting, vi forsøger at løse. Vores idé var for virksomheder som AMD, der i vid udstrækning ønsker at administrere deres egen infrastruktur, og optimere den på deres særlige måde, hvad de gerne vil have hjælp fra os til, er applikationsspecifikke beslutninger omkring hvilke typer instanser med hvilken mængde hukommelse der fungerer bedst, og måske konfigurationen af selve arbejdsbyrden. Hvordan kan de styre jobkørslerne for optimal ydeevne? Vi forsøger at pakke det hele sammen til noget, vi kalder en flyveplan. Vi har disse flyveplaner tilgængelige for forskellige dele af vores flow med basislinjeforslag. Hvis en kunde ønsker at bruge det, fantastisk. Hvis de vil riffe på det og forbedre sig fra det, er det også fint med os.

Aitken: Synopsys-visningen er den samme, men der er også en afhængighed af det specifikke design, du laver. Nogle designs vil bare kræve større eller højere forekomster end andre. Og afhængigt af, hvad din særlige arbejdsgang er, så vil nogle tilfælde give mere eller mindre mening end andre. Det er heller ikke kun licensomkostningerne. Det er også maskinomkostningerne i skyen, som du også skal udligne. Større maskiner er dyrere, men måske kan du køre din arbejdsbyrde på en mindre instans i længere tid og betale mere i licens, men mindre end beregningsgebyrer.

Et host: Vores fokus har været at se på det i forhold til, hvad selve løbeturen er. Er det en forudgående indtjekning? Med et pre-check-in vil du have et hurtigere løb med lav latency, så du får en virkelig højtydende instans til det. Er det en regression fra den ene dag til den anden? I så fald er jeg ikke nødvendigvis ligeglad med, hvor hurtigt den bliver færdig. Det skal bare afsluttes fra den ene dag til den anden, så det betyder, at jeg kan betale for billigere tilfælde for mine regressioner natten over. Vi samarbejder med vores cloud-udbyder for at finde ud af, hvad der er den bedste instans til at køre denne type job. Så er det et spørgsmål om at optimere omkostningerne. Du vil gerne holde dine omkostninger så lave som muligt, for som sagt stiger det ret hurtigt. Vi ser på hver enkelt arbejdsbyrde og siger: "Hvad er den instanstype, der skal til for det?" Samtidig bliver det svært, fordi du så skal administrere puljerne af instanser for hvert job, og så sørge for at have nok af den pulje af instanser til rådighed, så når det job rent faktisk starter, kører det på en rimelig måde. tidsramme. Når du kommer til implementeringen, skal du løse disse spørgsmål.

Turaga: Gennem årene har vi udviklet nogle bedste praksisser. I første omgang, når du ikke er sikker på, hvilken instanstype du skal bruge, vælger du noget med en balance mellem computer og hukommelse eller den generelle instanstype. Men når du ser på forskellige typer arbejdsbelastninger og verifikation, har du brug for lidt mere hukommelse. Det er det samme med timing. Du har brug for endnu mere hukommelse. Til CFD-analyse har du muligvis brug for GPU'er. Disse er en del af den bedste praksis, vi har udviklet, og som vi deler med kunderne.