Tradeoffs Between On-Premise And On-Cloud Design

Перевидано Платоном

читають: 0

Експерти за столом: Semiconductor Engineering обговорили, як і чому компанії розподіляють роботу локально та в хмарі, і на що слід звернути увагу, з Філіпом Штейнке, співробітником відділу інфраструктури САПР та фізичного проектування AMD; Махеш Турага, віце-президент із розвитку бізнесу хмарних технологій Системи проектування каденції; Річард Хо, віце-президент з розробки апаратного забезпечення Lightmatter; Крейг Джонсон, віце-президент із хмарних рішень Програмне забезпечення Siemens Digital Industries; і Роб Ейткен, співробітник Синопсис. Далі наведено уривки цієї розмови, яка відбулася перед живою аудиторією на конференції з автоматизації проектування. Перша частина цієї дискусії тут.

SE: З огляду на те, що сьогодні на кону так багато поставлено дизайн мікросхем, як досягти найкращої рентабельності інвестицій за допомогою хмарних ресурсів?

Штайнке: Вибираючи робочі процеси для включення хмари, ми почали з перегляду даних. Які з них мають керований набір даних, який можна інкапсулювати, перемістити в хмарний центр обробки даних для виконання певного роду обчислень, а потім мати розумну кількість результатів, які повертаються? Одним із напрямків, на якому ми зосередилися, була зовнішня перевірка. Я віддаю перевагу тому, щоб зберігати наші збірки на місці, об’єднувати саму модель разом із тестовим стимулом і надсилати це для виконання фактичної діяльності моделювання в хмарних обчисленнях. Інший клас робочих навантажень, для яких ми ввімкнули хмару, — це робочі навантаження перевірки повного чіпа, запуск повного чіпа для статичної синхронізації, фізичної перевірки та живлення — головним чином тому, що в середовищі типу "місце та маршрут" ви потрапляєте в регулярний каденція щоденних ECO або регулярних ECO, які відбуваються та вносять зміни, і вже є налаштування керування даними з випусками, що виконуються щодо дизайну. Тож ми можемо підключити цей механізм випуску, не просто помістити його в якийсь локальний том випуску в нашому власному центрі обробки даних, а потім перемістити ці дані в хмарний центр обробки даних, який було вибрано для виконання цих робочих місць. Одна з причин, яка викликає занепокоєння щодо такого великого робочого навантаження, полягає в тому, що якщо у вас уже є об’єднаний Oasis або якщо ви зібрали всі специфікації для свого дизайну, для якого ви хочете запустити статичну синхронізацію, це значна частина даних для переміщення все відразу. Але завдяки оновленню методології випуску на рівні блоку вони надходять у міру випуску кожного блоку протягом дня. Таким чином ви зможете почати роботу з аналізу повного чіпа, розміщену в хмарі, із меншою затримкою. Основна проблема, яку я там бачу, — це доступ до хороших хмарних віртуальних машин із достатньою пам’яттю для виконання цих великих завдань. Це ще один простір, який ми продовжуємо заохочувати наших хмарних партнерів пропонувати — рішення з великою кількістю оперативної пам’яті для компаній, що розробляють мікросхеми.

SE: Яку пораду ви можете дати щодо визначення того, коли робоче навантаження слід виконувати в prem, а не в хмарі?

Ейткен: Є цікава динаміка, яку ми бачимо лише в представниках цієї панелі, тому що Річард може підійти до цього й Філ будуть різними. Один дуже зосереджений на дизайні, який рухається через вершини та долини з точки зору потреб. В AMD, мабуть, постійно розробляють багато проектів, тож є початкові зусилля щодо того, що саме вони намагаються зробити. Яка інфраструктура має сенс, якщо ви намагаєтеся потрапити у світ, де ви збираєтеся виконувати всі свої розробки в хмарі, і ви взагалі не хочете мати локальний центр обробки даних? Ваш підхід до цього буде іншим, ніж якщо ви використовуєте хмару як засіб резервного копіювання та розширення для масивної інфраструктури, яку ви вже маєте.

SE: Практично кажучи, як ви вирішуєте?

Кашель: Ви подивіться на дані. Скільки у вас даних? Скільки даних ви збираєтеся згенерувати? А що вам потрібно назад? Головне, щоб зробити його успішним, щоб інформація, яку ви хочете, повертала з хмари. Он-прем має бути мінімальним, тому відображатимуться лише звіти та результати ваших регресій. Наша збірка фактично базується на нашій невеликій локальній системі. Ми доставляємо його та запускаємо наше моделювання, а також проводимо власний аналіз покриття. Потім ми відправляємо результати назад, і вони дуже маленькі, і це добре. Бекенд інший. Щодо фізичної частини дизайну, ви відправляєте дизайн туди, ви хочете, щоб він залишався в хмарі якомога довше, оскільки ці бази даних величезні, і ви справді не хочете, щоб він повертався взагалі. На цьому етапі це інфраструктура як послуга. Ви просто маєте своїх людей увійти в хмару та виконати всі фізичні розробки там, доки ви не отримаєте GDS. Це речі всередині машини — скільки пам’яті можна отримати? Це один з обмежувачів. Насправді мати дуже великі віртуальні машини в хмарі дуже дорого. Досить часто буває дешевше купити власний. Ми не говорили про вартість. Вартість хмари не така, як думають люди. Це досить високо. Досить часто це більше, ніж локально, тому вам потрібно збалансувати це, щоб отримати перевагу гнучкості та доступу до великих ресурсів пам’яті. І те, як це виглядає, буде дуже індивідуальним для кожного клієнта.

Джонсон: Це питання справді стосується рентабельності інвестицій. Це залежить від того, чого ви прагнете досягти як користувач середовища, і це є частиною завдання. Кожна компанія робить власний розрахунок на основі своєї стратегії, щоб з’ясувати, що вони хочуть робити в хмарі та наскільки агресивно вони готові витратити, щоб отримати цю вигоду. Іншим елементом є прибуток, який ви вимірюєте, відрізняється від вартості володіння. Ми, як правило, краще проводимо аналіз загальної вартості володіння, ніж частина «R» рентабельності інвестицій, яка потім має включати в гру більше нематеріальних факторів, часу пропускної здатності та переваги часу виходу на ринок.

Ейткен: Навіть із такою простою справою, як затримка, коли ви запускаєте інструмент і час відповіді такий: «Я перевів мишу, а потім через деякий час щось трапилося», це може дуже засмучувати.

Турага: Історично, якщо ми поглянемо на рентабельність інвестицій для хмари, існує три класи інструментів, які можуть дуже ефективно використовувати хмару. По-перше, це організація проектування, ітерації проектування, регресії з перевіркою. По-друге, там, де є тривалі симуляції з великими обчислювальними навантаженнями, і вони можуть дуже добре масштабуватися, щоб скористатися перевагами обчислювальних алгоритмів у різних випадках. По-третє, це інтерактивний тип, наприклад інструменти, які вимагають затримки, а також вимагають значного зростання співпраці. Це три категорії інструментів, які отримують найкращу рентабельність інвестицій від хмари. І знову ж таки, залежно від ситуації кожного клієнта, це залежить від того, який інструмент вони хочуть запустити в хмарі. Деякі з наших клієнтів почали з перевірки, але це залежить від конкретної ситуації клієнта.

SE: Стосовно хмарних користувачів, як ви прийшли до рішень щодо своєї моделі використання хмари?

Штайнке: Ми тут деякий час. У нас уже був досить великий центр обробки даних, тому нам не потрібно було йти ва-банк на початку. Ми прагнули доповнити те, що маємо, тим, що може запропонувати хмара. Наш локальний центр обробки даних продовжує забезпечувати величезну кількість нашої обчислювальної потужності. Проекти приходять і йдуть, і трапляються несподівані речі; Можливість використовувати таку гнучкість і мати кілька джерел обчислень, з яких ми можемо використовувати, є перевагою, якою ми хотіли скористатися. Це було значною частиною нашої мотивації для хмари, і чому ми пішли таким шляхом. У нас уже були ці початкові інвестиції, тож ми хотіли розширити та розвинути їх.

Кашель: Я можу відповісти на це з двох точок зору. Перша перспектива полягає в тому, що до того, як я прийшов у Lightmatter, я працював у Google над TPU та командою інфраструктури, і ми також використовували там хмару. Відповідь там відрізняється від відповіді на Lightmatter. Одне із запитань, яке ви повинні задати собі, це те, чи хочете ви, щоб ваше репо (репозиторій) було локальним або в хмарі. У такій компанії, як Google і, мабуть, AMD, вони хочуть, щоб їхнє репо було локальним. Вони почуваються в більшій безпеці, їм здається, що все більше під їх контролем. У меншій компанії, як-от Lightmatter, мені не обов’язково це цікаво. Мене влаштовувала безпека хмари, тому я можу мати репо в хмарі. І в цьому меншому контексті наявність репозиторію в хмарі означає, що ми використовуємо хмару майже як повну інфраструктуру. Це те саме, що й у мене на премії. Це перше занепокоєння. Друга проблема – спадщина. Деякі компанії мають застаріле рішення, і коли ви намагаєтеся перейти від застарілого до хмарного рішення, ви дійсно повинні розуміти, що ви отримуєте, що говорить про мету цієї панелі. Ми намагаємося вказати, де ви отримуєте вигоду з точки зору гнучкості, з точки зору можливості мати новіші машини тощо. Де це дійсно має значення, це деякі з цих робочих навантажень, де у вас багато паралельних прогонів. Ви хочете керувати великою кількістю серверів і запущених завдань, і ось куди вам слід перейти в хмару. Ви можете збільшити робоче навантаження, скориставшись цим. Потім, повертаючись до потоку даних, де у вас є обмеження, ви повинні прийняти рішення. Ми прийняли рішення мати репо для фізичного дизайну в хмарі, але інші компанії цього не зробили. Я знаю, що компанії мають більше. Вони зробили багато фізичного дизайну ще на премі, тому що їм потрібно багато пам’яті та не так багато машин. Тож ви повинні розглянути кожен із цих випадків і прийняти рішення на основі вашої ситуації.

Турага: Багато наших малих і середніх стартапів не бажають локального репо. У них немає проблем із застарілим центром обробки даних, тому вони справді повністю використовують хмару. Деякі з великих компаній, які вже мають величезну локальну інфраструктуру, вже переходять на модель гібридного типу.

SE: З огляду на майже дивовижну кількість типів інстанцій, доступних у хмарі від різних постачальників, на додачу до витрат на ліцензування, які ще не оптимізовані для хмари, як користувачі можуть покращити спосіб вибору правильного типу інстансу для виконання своїх завдань?

Джонсон: Це одна з основоположних речей, яку ми намагаємося вирішити. Наша ідея полягала в тому, що для таких компаній, як AMD, які переважно хочуть керувати власною інфраструктурою та оптимізувати її у свій спосіб, вони хотіли б отримати від нас допомогу щодо рішень щодо конкретних програм щодо того, які типи екземплярів із яким об’ємом пам’яті найкраще працюють, і, можливо, конфігурація самого робочого навантаження. Як вони можуть керувати виконанням завдань для досягнення оптимальної продуктивності? Ми намагаємося скласти все це в щось, що ми називаємо планом польоту. Ми маємо ці плани польотів для різних частин нашого потоку з базовими пропозиціями. Якщо клієнт хоче цим скористатися, чудово. Якщо вони хочуть риффувати на цьому та вдосконалюватися від цього, це також добре для нас.

Ейткен: Погляд Synopsys такий самий, але також існує залежність від конкретного дизайну, який ви робите. Деякі проекти просто вимагатимуть більших або вищих екземплярів, ніж інші. І залежно від конкретного робочого процесу деякі екземпляри матимуть більший або менший сенс, ніж інші. Крім того, справа не лише у витратах на ліцензування. Крім того, вам доведеться поступитися ціною машини в хмарі. Більші машини коштують дорожче, але, можливо, ви зможете довше працювати на меншому екземплярі та платити більше за ліцензію, але менше, ніж за обчислення.

Кашель: Ми зосередилися на тому, щоб поглянути на це з точки зору фактичного пробігу. Це попередня реєстрація? З попередньою реєстрацією вам потрібен швидший запуск із низькою затримкою, тож для цього ви отримаєте дійсно високопродуктивний екземпляр. Чи це нічний регрес? У такому випадку мене не хвилює, як швидко це закінчиться. Його просто потрібно завершити за ніч, тож я можу заплатити за дешевші екземпляри для своїх нічних регресій. Ми працюємо з нашим хмарним постачальником, щоб визначити, який екземпляр є найкращим для виконання такого типу роботи. Далі – питання оптимізації витрат. Ви хочете, щоб ваші витрати були якомога нижчими, оскільки, як я вже сказав, вони ростуть досить швидко. Ми розглядаємо кожне конкретне робоче навантаження і кажемо: «Який тип екземпляра для цього потрібен?» У той же час це стає складно, тому що вам потрібно керувати пулами екземплярів для кожного завдання, а потім переконатися, що у вас є достатньо цього пулу екземплярів, щоб, коли це завдання фактично розпочнеться, воно виконувалося в розумному режимі. період часу. Приступаючи до розгортання, ви повинні відповісти на ці запитання.

Турага: За ці роки ми розробили кілька найкращих практик. Спочатку, коли ви не впевнені, який тип екземпляра використовувати, ви вибираєте щось із балансом між обчисленням і пам’яттю або цей загальний тип екземпляра. Але коли ви розглядаєте різні типи робочих навантажень і перевірку, вам потрібно трохи більше пам’яті. Те ж саме стосується часу. Вам потрібно ще більше пам’яті. Для аналізу CFD вам можуть знадобитися графічні процесори. Це частина розроблених нами передових практик, якими ми ділимося з клієнтами.