Додаток "не підтримується" у вітчизняному комп'ютері?

Ми придбали певне програмне забезпечення у невеликої компанії, це 32-розрядний менеджер робочого процесу для відеоконтенту для Windows, там відбулися деякі налаштування.

Ми працюємо чудово вже понад рік, використовуючи цей код у VMWare ESXi 4.1u2 VM на W2K3EE-32-бітному (саме так вони підтримують його запуск).

Потім вони оновлювали свій код місяць або близько того назад, і ми почали бачити, що один з vCPU періодично прив'язується до 100%, другий vCPU досить простою, скажімо, 5-7% - тому ми просто припустили, що код погано введено в дію і зв’язався з ними це.

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

На щастя, у нас є кілька фізичних осіб, які ми можемо це зробити, трохи забираючи багато часу, але виконати.

Однак моє запитання полягає в тому, що, враховуючи, що цей VM не торкається жодного обладнання безпосередньо, він знаходиться на дуже сучасному хості і насправді має дуже низькі вимоги (2 x vCPU, 4GB, 20GB завантажувальний vdisk, 100 Гб даних vdisk, один vNIC і більше нічого) Можливо, може виникнути проблема із його запуском у віртуальній машині, якщо така є?

Очевидно, що я сильно переслідую це з ними, але мені просто було цікаво, чи хтось знайшов регулярне застосування, що якимось чином не поводиться всередині ВМ, але не фізично.

Хоча я не можу говорити за цього постачальника або пакет програмного забезпечення, я працював у великого (багатонаціонального) постачальника, де одна з програм, які вони продавали, мала дуже специфічні відомі проблеми під час роботи на VMware.

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

Тож, хоча це рідко, можуть бути випадки, коли програмне забезпечення працює не так, як ви очікували б у VMware.

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

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

З ESX v5 та обмеженням Monster VM (32ВCPU 1 ТБ ОЗУ) кількість додатків, що мають проблеми з VM, скорочується. Більшість з тих, що я відчував, це або: - покладатися на час, щоб бути лінійним (процеси в реальному часі або додатки, які потребують лінійного часу ... це, як правило, можна налаштувати) - програми, що спричиняють багато апаратних перерв або переключення контексту.

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

Що стосується рішення, у мене була подібна проблема з VM, що має високе використання процесора (але хост, у якому є безліч ресурсів процесора). Ми вирішили цю проблему, перемістивши на сервер з процесором Nehalem та змінивши рівень сумісності процесора в EVC (якщо у вас є кластер з DRS / HA)

Я бачив подібну проблему з VMware ESX + Debian 6 + OpenLDAP 2.4.x (незалежно від того, яка версія версії OpenLDAP підходить для отримання ...).

Під час щоденних операцій це працює нормально, але такі речі, як імпорт великого LDIF-файлу з 400 000 або більше записів, дуже повільні (на 50-100 разів повільніше, ніж на фізичних серверах). Крім того, з тривалим високомасштабним тестуванням все проходить гладко, з часом декількох мілісекунд часу відгуку, але періодично трапляються дивні піки від 500 до 25 000 (!) Мілісекунд.

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