Порівняння KVM та VMware для віртуалізації підприємства

Інформатек Діджитал » Ресурси » Порівняння KVM та VMware для віртуалізації підприємства

Якщо ви вагаєтеся між налаштуванням інфраструктури на KVM чи VMware (або просто хочете краще зрозуміти, що пропонує кожен з них), цей посібник містить детальне порівняння: продуктивність, безпека, ліцензування, підтримка, сумісність контейнерів, резервне копіювання, кластеризація, мережа, формати дисків, інтеграція з іншими компонентами, такими як OpenStack або Active Directory… ідея полягає в тому, що до кінця читання ви матимете чітке розуміння того, в якому сценарії кожен варіант найкраще підходить.

Що таке KVM та VMware і чим вони схожі?

VMware, зі свого боку, є компанією, яка стоїть за цілим сімейством продуктів для віртуалізації. У контексті центрів обробки даних ключовим гравцем є VMware ESXi , гіпервізор типу 1, який формує ядро ​​платформи VMware vSphere . Навколо ESXi обертаються vCenter, vSAN, NSX, Horizon, Tanzu та багато інших компонентів, що утворюють дуже зрілу екосистему для вимогливих корпоративних середовищ.

Як KVM, так і ESXi — це гіпервізори типу 1 без підзарядки, здатні запускати кілька віртуальних машин (ВМ) з гостьовими операційними системами, такими як Windows, Linux, BSD або Solaris, з підтримкою апаратної віртуалізації (Intel VT-x, AMD-V). Концептуально обидва дозволяють надавати віртуальні машини, ізолювати їх, створювати міграції в реальному часі , створювати знімки та керувати великими кластерами. Різниця полягає в тому, як ці функції реалізуються, в їхній вартості, гнучкості та адміністративних можливостях, що пропонуються кожним з них.

Типи гіпервізорів та внутрішня архітектура

У віртуалізації зазвичай розрізняють гіпервізори типу 1 (на голому металі) та типу 2 (встановлені поверх операційної системи). KVM та ESXi належать до типу 1, тоді як такі продукти, як VMware Workstation, VMware Player, VMware Fusion та VirtualBox, належать до типу 2.

У випадку KVM , хоча він встановлюється як частина хоста Linux, він вважається гіпервізором типу 1, оскільки ядро ​​Linux діє як прямий гіпервізор на обладнанні. Таким чином, KVM успадковує планувальник процесора, управління пам'яттю та мережевий стек від самого Linux, що надає йому значну гнучкість та сумісність з обладнанням.

ESXi — це власна мінімальна операційна система VMware, розроблена спеціально як гіпервізор. Вона має закрите ядро , інтегроване із сертифікованими та оптимізованими драйверами, і використовує площину управління VMware для взаємодії з апаратним забезпеченням та рештою пакету (vCenter, NSX тощо). Такий підхід зменшує обсяг програмного забезпечення до того, що абсолютно необхідно для віртуалізації.

Окрім розмежування між Типом 1 та Типом 2, важливо розуміти різницю між повною "голою" віртуалізацією та апаратно-допоміжною віртуалізацією . У повністю програмній повній віртуалізації гіпервізор емулює все обладнання та транслює інструкції процесора (двійкове перетворення), що повільніше, але дозволяє йому працювати без VT-x/AMD-V. При апаратно-допоміжній віртуалізації деякі інструкції vCPU виконуються безпосередньо на фізичному процесорі, що значно зменшує накладні витрати. KVM та ESXi покладаються на останній підхід для забезпечення високої продуктивності.

Продуктивність: Що працює краще: KVM чи VMware?

Сира продуктивність KVM та ESXi дуже схожа в більшості виробничих сценаріїв. KVM побудовано приблизно на 10 000 високооптимізованих рядках коду в ядрі Linux, що зменшує накладні витрати, а завдяки QEMU та virtio він досягає майже нативної продуктивності для процесора, диска та мережі.

У випадку VMware ESXi вихідний код є власним, але повний продукт, за оцінками, містить десятки мільйонів рядків, якщо врахувати всі компоненти екосистеми. У деяких синтетичних тестах було виявлено, що віртуальні машини трохи швидші на KVM, ніж на ESXi, але в реальних корпоративних середовищах відмінності зазвичай незначні порівняно з іншими вузькими місцями, такими як сховище даних або мережа.

VMware отримує перевагу в сценаріях, що включають оптимізацію планування, DRS, vMotion та Storage vMotion , що дозволяє балансувати навантаження та переміщувати віртуальні машини в режимі «гарячого» режиму з мінімальним впливом, підтримуючи дуже стабільну продуктивність навіть за великої кількості завантаженого кластера.

З іншого боку, KVM особливо добре працює в середовищах, де Linux вже добре розвинений, а ядро ​​(регулятор процесора, планувальник вводу/виводу, hugepages, NUMA тощо) та мережевий стек можна точно налаштувати. Спільне використання ядра з хостом дозволяє дуже швидко впроваджувати апаратні покращення, вбудовані виробниками в ядро ​​Linux.

Інструменти встановлення, складності та управління

Крива навчання — це одна з областей, де різниця між KVM та VMware найбільш помітна. У випадку з KVM інсталяція включає спочатку налаштування системи Linux (Ubuntu, RHEL, CentOS, Oracle Linux, SUSE тощо) та встановлення необхідних пакетів: KVM/QEMU, libvirt , інструментів керування, таких як virt-manager або virt-install, і, за потреби, ручне налаштування віртуального комутатора, мостів та з'єднання . Це дуже гнучко, але вимагає значного розуміння екосистеми Linux.

У VMware ESXi робочий процес більш керований: ви завантажуєте ISO-образ, записуєте його на USB-накопичувач або компакт-диск, завантажуєте сервер і виконуєте дуже простий графічний майстер . Наступним кроком зазвичай є розгортання vCenter Server Appliance (попередньо налаштованої віртуальної машини) з цього ISO-образу, і з цього моменту практично всім керує веб-інтерфейс vSphere Client.

Щодня керування KVM здійснюється за допомогою таких інструментів, як virsh (інтерфейс командного рядка для libvirt) та virt-manager (графічний інтерфейс робочого столу для керування кількома хостами KVM), а також SSH, VNC або SPICE для підключення до консолей віртуальних машин. Доступні веб-інтерфейси, такі як Kimchi та Foreman, а такі проекти, як oVirt та Red Hat Virtualization, додають розширений візуальний рівень поверх KVM.

У VMware vSphere наріжним каменем управління є vCenter з його веб-клієнтом vSphere Client , з якого керуються хости ESXi, кластери, віртуальні мережі, сховища даних, висока доступність, DRS, vSAN, NSX тощо. Крім того, є ESXCLI для командного рядка, PowerCLI (на основі PowerShell) для автоматизації майже всього та інтерфейс Host Client для автономних хостів ESXi без vCenter.

Вартість, ліцензії та модель підтримки

Що стосується вартості, різниця очевидна: KVM — це програмне забезпечення з відкритим вихідним кодом , інтегроване в Linux, яке не вимагає ліцензій гіпервізора як такого. Воно доступне на будь-якому сучасному дистрибутиві Linux з моменту інтеграції в ядро ​​у 2007 році. Витрати покриваються комерційною підтримкою (Red Hat, SUSE, Oracle тощо) та будь-якими додатковими інструментами управління, які ви можете захотіти додати, але основний функціонал безкоштовний.

VMware vSphere — це комерційне рішення, яке зазвичай ліцензується на процесор/ядро та версію (Standard, Enterprise Plus тощо). Воно включає ліцензії на ESXi та vCenter, і якщо ви хочете додати такі продукти, як NSX, vSAN, Tanzu, Horizon або vRealize , для кожної з них потрібна власна додаткова ліцензія. Існує безкоштовна версія ESXi (vSphere Hypervisor), але вона має суттєві обмеження : API лише для читання, відсутність керування vCenter, відсутність технічної підтримки та відсутність можливості використовувати рішення для резервного копіювання, які залежать від цих API.

Що стосується підтримки, VMware пропонує цілодобову корпоративну підтримку відповідно до контракту, з доступом до бази знань, оновлень, патчів та прямої допомоги. З KVM «офіційна» підтримка залежить від вашого постачальника розповсюджувачів (Red Hat, Oracle, SUSE тощо) або вашої власної ІТ-команди, і ви завжди маєте підтримку дуже активної спільноти, але немає жодного постачальника KVM, якому можна було б подати заявку на підтримку, якщо ви не уклали контракт з певним постачальником.

Сумісність обладнання та обмеження масштабування

Сумісність обладнання – ще один фактор, що відрізняє його. Оскільки KVM базується на Linux , він успадковує широкий список обладнання, що підтримується ядром: процесори x86 з VT-x/AMD-V , різні типи контролерів дисків, мережеві адаптери, архітектури, такі як ARM або PowerPC у певних варіантах, тощо. Поки ядро ​​має драйвер, KVM зазвичай може працювати на цьому хості без особливих проблем.

VMware ESXi вимагає, щоб сервер та компоненти були в списку сумісного обладнання (HCL) . Це гарантує сертифіковані драйвери та оптимальну продуктивність, але обмежує його використання на старішому або дуже новому обладнанні, яке ще не пройшло процес сертифікації. У великих проектах це може збільшити вартість платформи через необхідність придбання спеціального обладнання, рекомендованого VMware.

Що стосується обмежень, комерційні дистрибутиви, що містять KVM, надають орієнтовні цифри. Наприклад, для певних середовищ підтримуються значення до 384 ядер процесора та 6 ТБ оперативної пам'яті на хост , з приблизно 600 одночасними віртуальними машинами, а також до 256 віртуальних процесорів (або більше в останніх версіях) та кількох терабайтів віртуальної оперативної пам'яті на одну віртуальну машину . Це залежить від дистрибутива (Red Hat, Oracle Linux, SUSE) та тестів валідації, що проводяться кожним постачальником.

У VMware vSphere офіційна документація встановлює дуже високі обмеження: до 896 логічних процесорів та 24 ТБ оперативної пам'яті на хост ESXi , 1024 віртуальні машини на хост, 4096 агрегованих віртуальних процесорів (vCPU), 256 віртуальних процесорів на віртуальну машину, понад 6 ТБ оперативної пам'яті на віртуальну машину, віртуальні диски до 62 ТБ та кластери до 64 хостів та 8000 віртуальних машин . На рівні vCenter можна керувати до 2500 хостів ESXi та 40 000 віртуальних машин на екземпляр, що залишає значний простір для зростання.

Безпека: ізоляція, шифрування та відповідність вимогам

Безпека гіпервізора є критично важливою: якщо хтось скомпрометує хост, у нього відкриються двері до всіх віртуальних машин та їхніх даних. KVM використовує екосистему безпеки Linux для посилення ізоляції. Його ключовою особливістю є комбіноване використання SELinux (Security-Enhanced Linux) та sVirt (Secure Virtualization) . SELinux визначає обов'язкові політики контролю доступу (MAC), а sVirt поширює ці політики на віртуальні машини, позначаючи процеси та образи дисків, щоб ізолювати їх один від одного.

Крім того, ви можете використовувати iptables/nftables для розширеного брандмауера, безпечного завантаження UEFI на гостьових машинах (з деяким ручним налаштуванням) та технологій шифрування пам'яті, таких як TME/MKTME, на сумісному обладнанні. На рівні диска KVM дозволяє прозоро для гостьової системи шифрувати образи QCOW2 за допомогою 128-бітного AES або делегувати шифрування файловій системі хоста чи самій гостьовій операційній системі.

VMware vSphere також перевершує інші переваги в цій галузі, маючи набір функцій, розроблених для регульованих середовищ (HIPAA, PCI DSS тощо). Він пропонує інтегрований брандмауер в ESXi , підтримку Secure Boot UEFI, інтеграцію з TPM та vSphere Trust Authority, детальне керування дозволами та ролями, а також шифрування віртуальної машини з інтеграцією із зовнішньою KMS або рідним постачальником ключів vSphere.

Віртуальні машини у VMware можуть використовувати vTPM та безпеку на основі віртуалізації, а NSX забезпечує розподілену сторонню безпеку (мікросегментація, розподілений брандмауер, IDS/IPS залежно від редакції). Крім того, VMware пропонує інструменти моніторингу відповідності та забезпечення конфігурації гіпервізора, що спрощує узгодження платформи з суворими нормами.

Віртуальні мережі та підключення

На мережевому рівні KVM спирається на можливості ядра Linux та спеціальних інструментів. Для віртуальних комутаторів зазвичай використовується Open vSwitch (OVS) , що забезпечує публічні або приватні віртуальні мости, розподілену комутацію між хостами та підтримку VLAN, VXLAN, QoS та інших розширених функцій. Також можна створювати класичні мости Linux, а об'єднання в команди (bonding) або об'єднання в команди (teaming) можна використовувати для додавання каналів або налаштування резервування.

Мережеві інтерфейси Virtio підтримують віртуальні локальні мережі (VLAN) та можуть бути оркестровані за допомогою libvirt , яка включає керування віртуальною мережею та DHCP-сервер, інтегрований у QEMU. Можливості брандмауера такі ж широкі, як і сам мережевий стек Linux, а VXLAN, тунелі, VPN та багато іншого можна налаштувати за допомогою стандартних інструментів екосистеми.

У VMware vSphere мережа базується на двох типах комутаторів: стандартному vSwitch (налаштовується для кожного хоста) та розподіленому vSwitch (централізованому з vCenter). Обидва підтримують VLAN, об'єднання мережевих карт для балансування навантаження та відновлення після відмови, а також базові політики безпеки. Для розширених програмно-визначених мереж (мікросегментація, VXLAN, балансувальники навантаження, розподілені політики) використовується VMware NSX.

Налаштування агрегації каналів, груп портів, політик трафіку або мереж для vMotion та сховища зазвичай зручніше для користувача в графічному інтерфейсі vSphere, ніж робити все це через CLI в Linux, хоча KVM пропонує більше свободи для «екзотичних» сценаріїв, якщо ви знайомі з iproute2, OVS тощо.

Зберігання, формати дисків та міграція

За допомогою KVM практично все, що Linux може монтувати як фізичне або логічне сховище, можна використовувати: диски SAS, SATA, NVMe, томи LVM, NFS, iSCSI, SAN, NAS тощо. Віртуальні машини можуть використовувати образи віртуальних дисків або Raw Device Mapping (передача даних через пристрій або том). Також можливо безпосередньо підключити том LVM до віртуальної машини.

Рідні формати зображень – це raw (img) та qcow2 . Формат raw дуже простий і швидкий (приблизно на 10% швидший, ніж формати з додатковими шарами), але він не підтримує внутрішні знімки або інкрементальні резервні копії на рівні блоків. Qcow2, з іншого боку, пропонує знімки, стиснення, шифрування, тонке резервування та підтримку TRIM/UNMAP , що дозволяє повертати невикористаний простір за допомогою таких інструментів, як virt-sparsify. Крім того, KVM розуміє інші формати, такі як VMDK (від VMware), VDI (VirtualBox), VHDX (Hyper-V) та багато інших, що спрощує міграцію між платформами.

У VMware ESXi формат диска за замовчуванням – VMDK . Кожен диск зазвичай складається з дескриптора .vmdk та плоского файлу .vmdk, що містить дані. Підтримується тонке та товсте виділення ресурсів, а сховище даних зазвичай розміщується на VMFS або NFS. Диски можуть використовувати автоматичне скасування зіставлення для звільнення простору, а для безпосереднього зіставлення LUN з віртуальними машинами можна використовувати Raw Device Mapping (RDM).

Для міграції віртуальних машин KVM пропонує міграцію в реальному часі між хостами, якщо вони використовують спільне сховище, а також міграцію сховища (переміщення файлів віртуальної машини на інший хост) у певних сценаріях, з планами розширити міграцію сховища в реальному часі. VMware роками пропонує vMotion (міграцію віртуальних машин у реальному часі між хостами) та Storage vMotion (міграцію дисків між сховищами даних без вимкнення віртуальної машини), обидва високоякісні та добре інтегровані в управління кластером.

Кластеризація, висока доступність та балансування навантаження

У кластеризації KVM пропонує компоненти, але не «закритий» продукт, порівнянний з vSphere. Для високої доступності такі інструменти, як DRBD (реплікація блоків по мережі), Heartbeat та Pacemaker, використовуються як менеджери ресурсів кластера. Налаштування резервного копіювання між вузлами можливе , але зазвичай це вимагає багатьох ручних операцій та значного досвіду.

Автоматизоване балансування навантаження не є стандартною функцією; зазвичай воно спирається на такі проекти, як oVirt або Red Hat Virtualization , які створюють розширений рівень управління поверх KVM для забезпечення автоматичних міграцій на основі навантаження, високої доступності (HA), політик та інших факторів. Загалом, налаштування добре налаштованого кластера KVM з HA не є простим без комерційного рішення, яке його включає.

На противагу цьому, VMware vSphere вирізняється саме своїми можливостями кластеризації. Такі функції, як vSphere HA, дозволяють автоматично перезапускати віртуальні машини на інших хостах у разі збою вузла, а DRS (Distributed Resource Scheduler) перерозподіляє навантаження, переміщуючи віртуальні машини між хостами за допомогою vMotion на основі політик споживання процесора та оперативної пам'яті. Для певних віртуальних машин також доступна відмовостійкість , яка підтримує репліку в режимі реального часу та забезпечує безперебійну роботу у разі збою хоста.

Крім того, розподілене керування живленням може вимикати хости, коли навантаження низьке, та перезапускати їх за потреби, заощаджуючи енергію без шкоди для ємності. Налаштування цих механізмів досить просте з клієнта vSphere, що робить VMware найзручнішим варіантом, якщо вам потрібна складна кластеризація без проблем із консоллю.

Сумісність гостьової системи та контейнера

Як KVM, так і VMware ESXi підтримують широкий спектр гостьових операційних систем: Windows (від дуже старих версій, таких як NT або 95, до сучасних), багато дистрибутивів Linux (Ubuntu, Debian, RHEL, CentOS, Fedora, Oracle Linux, SUSE, Kali тощо), похідні BSD (FreeBSD, OpenBSD), Solaris, OpenSolaris, NetWare, MS-DOS і навіть macOS з певними налаштуваннями та обмеженнями.

Різниця полягає в інтеграції зі світом контейнерів . За допомогою KVM можна запускати Docker або Kubernetes всередині віртуальних машин, як і з будь-яким іншим гіпервізором, але також існують спеціальні драйвери (docker-machine-driver-kvm) , які дозволяють прозоро створювати машини Docker поверх KVM, покращуючи ізоляцію та продуктивність порівняно з ручним налаштуванням віртуальних машин. Крім того, KVM дуже добре інтегрується з OpenStack , де він класифікується як група A (максимальна сумісність) і часто є кращим гіпервізором у приватних хмарах Linux.

VMware, зі свого боку, зробила перший крок з vSphere Integrated Containers (запуск контейнерів як легких віртуальних машин за допомогою Photon OS) і зробила значний крок вперед з VMware Tanzu , яка інтегрує Kubernetes і контейнери безпосередньо в ESXi. Tanzu перетворює хости ESXi на вузли Kubernetes (за допомогою Spherelet), надає площину керування для DevOps, керується з vCenter і використовує NSX-T та спільне сховище для створення комплексного середовища корпоративних контейнерів (хоча й з додатковими витратами на ліцензування).

Коротше кажучи, якщо ви активно працюєте в хмарних екосистемах на базі Linux, KVM + OpenStack/Kubernetes чудово вам підійде; якщо ж ви вже маєте значні інвестиції у VMware та шукаєте контейнери, інтегровані у вашу платформу vSphere з усіма мережевими та безпековими додатковими функціями, Tanzu — потужний варіант.

Інтеграція з іншими компонентами: AD, OpenStack та екосистема

VMware vSphere нативно інтегрується з Microsoft Active Directory для автентифікації та контролю доступу на основі ролей. Користувачі можуть входити в клієнт vSphere, використовуючи свої облікові дані домену, та призначати детальні дозволи об'єктам (віртуальним машинам, сховищам даних, кластерам тощо). Крім того, пакет VMware бездоганно інтегрується з: NSX для мереж, vSAN для програмно-визначеного сховища, Horizon для VDI, vRealize для автоматизації та моніторингу тощо.

У світі KVM інтеграція з Active Directory цілком можлива шляхом приєднання хоста Linux (або віртуальних машин) до домену, але налаштування передбачає роботу з такими інструментами, як sssd, winbind або realmd. Для хмарної оркестрації KVM сяє з OpenStack , де він є кращим вибором (Група A), тоді як ESXi класифікується як Група B: підтримується, але дещо менш пріоритетний в екосистемі OpenStack.

Щодо прив'язки до постачальника, KVM, будучи програмним забезпеченням з відкритим вихідним кодом та без прив'язки до певного постачальника , дозволяє інтеграцію практично з будь-яким комерційним або відкритим програмним забезпеченням, адаптуючи стек до ваших потреб. У VMware, за своєю суттю, ви схильні будувати рішення навколо його площини керування та продуктів, що забезпечує значну узгодженість, але також прив'язує вас до його ліцензій та дорожньої карти.

Резервне копіювання, реплікація та захист даних

Спосіб резервного копіювання віртуальних машин також суттєво відрізняється. У KVM основні методи передбачають використання virsh та знімків дисків. Якщо для віртуальних машин використовуються томи LVM, знімки LVM можна створювати та резервувати з цих томів, що забезпечує дуже хорошу продуктивність, але ускладнює міграцію та управління простором.

З необробленими образами резервне копіювання можливе лише при вимкненій віртуальній машині, оскільки немає вбудованої підтримки знімків на рівні образів. За допомогою qcow2 знімки можна створювати на запущеній віртуальній машині (для чого потрібен гостьовий агент QEMU в гостьовій операційній системі та налаштування каналу org.qemu.guest_agent.0), а потім дані можна копіювати послідовно. Існують рішення, які використовують libvirt та oVirt для реалізації інкрементального резервного копіювання на основі змін блоків.

Для реплікації KVM може використовувати DRBD на рівні блоків ядра Linux, синхронно реплікуючи диски між вузлами для монтування кластерів високої доступності, хоча зазвичай без шифрування, якщо трафік не інкапсульовано в VPN або подібні мережі.

У VMware vSphere захист даних є надійним завдяки API захисту даних vStorage . Постачальники резервного копіювання (Veeam, NAKIVO тощо) використовують ці API для створення узгоджених знімків працюючих віртуальних машин із зупинкою програм через інструменти VMware, а також для використання відстеження змінених блоків (CBT) , яке забезпечує високоефективне інкрементне резервне копіювання шляхом копіювання лише змінених блоків.

Рішення для резервного копіювання для VMware зазвичай підтримують миттєве відновлення віртуальних машин , детальне відновлення файлів або об'єктів програм (Exchange, SQL, AD тощо) та реплікацію між хостами або сайтами ESXi. Безкоштовна версія ESXi не надає ці API, тому в такому випадку вам знадобляться скрипти та ручне резервне копіювання вимкнених віртуальних машин, що зазвичай неприйнятно у виробничому середовищі.

Зрештою, якщо захист даних на рівні гіпервізора та інтеграція з численними комерційними рішеннями для резервного копіювання є ключовими, vSphere пропонує більш зрілу та однорідну екосистему. KVM дозволяє використовувати надійні стратегії, але з ширшим спектром підходів та більшою залежністю від досвіду команди та обраних інструментів.

Коли варто використовувати KVM, а коли VMware?

Вибір між KVM та VMware полягає не в тому, хто «кращий» в абсолютному вираженні, а радше у виборі правильного інструменту для контексту. Для організацій з обмеженим бюджетом , сильною культурою Linux та бажанням налаштувати платформу, KVM є дуже привабливим: він не вимагає ліцензій гіпервізора, пропонує широку сумісність з обладнанням та надає розширені можливості налаштування. Він ідеально підходить для стартапів, невеликих постачальників VPS, тестових лабораторій, середовищ, орієнтованих на Linux, або приватних хмар на базі OpenStack.

VMware ESXi та vSphere найкраще підходять для середовищ, які потребують високоінтегрованого підходу, сильної комерційної підтримки та спрощеного управління великими кластерами. Компанії, які вже використовують продукти VMware (Horizon, NSX, vSAN, Tanzu), мають суворі вимоги до доступності, відповідності та цілодобової підтримки, або цінують високоякісну централізовану консоль, зазвичай надають перевагу інвестуванню в ліцензії vSphere та будівництву своєї стратегії віртуалізації навколо цієї екосистеми.

З практичної точки зору, KVM — це високопродуктивне та недороге рішення , яке винагороджує команди з досвідом роботи з Linux та толерантністю до дещо більшої складності. VMware, з іншого боку, пропонує більш «закритий, але зручний» досвід: ви платите за ліцензії та обслуговування, але натомість отримуєте надзвичайно зрілу платформу віртуалізації з розширеною кластеризацією, тонко налаштованими інструментами резервного копіювання та дуже надійною інтеграцією з рештою свого стеку.