ДК 021:2015 – 30210000-4 «Машини для обробки даних (апаратна частина)» (гіперконвергентний обчислювальний комплекс – для потреб Міністерства охорони здоров'я України)

СКАРГА на порушення Замовником законодавства з питань публічних закупівель

Скарга

Скарга

Скарга

Суб’єкт оскарження: ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ "СІТІУС ПРО" Код ЄДРПОУ: 41644946 Юридична адреса: 04050, М.КИЇВ, ВУЛИЦЯ МЕЛЬНИКОВА, БУДИНОК 81, ЛІТЕРА А Тел.: +380 (044) 390-88-18, office@citius.pro Замовник, дія якого оскаржується: ДЕРЖАВНА УСТАНОВА "ПРОФЕСІЙНІ ЗАКУПІВЛІ" Код ЄДРПОУ: 40996564 Адреса Замовника: 01601, Україна, Київ обл., Київ, вулиця Бульварно-Кудрявська, 22 Скарга на дії та рішення Замовника, що порушують Законодавство України про публічні закупівлі (далі – Закон) у торгах ДЕРЖАВНА УСТАНОВА "ПРОФЕСІЙНІ ЗАКУПІВЛІ" № UA-2018-07-20-001358-c від 20.07.2018 «ДК 021:2015 – 30210000-4 «Машини для обробки даних (апаратна частина)» (гіперконвергентний обчислювальний комплекс – для потреб Міністерства охорони здоров'я України)» ТОВАРИСТВО З ОБМЕЖЕНОЮ ВІДПОВІДАЛЬНІСТЮ «СІТІУС ПРО» (далі – Скаржник) приймає участь у торгах ДЕРЖАВНОЇ УСТАНОВИ "ПРОФЕСІЙНІ ЗАКУПІВЛІ" № UA-2018-07-20-001358-c від 20.07.2018 «ДК 021:2015 – 30210000-4 «Машини для обробки даних (апаратна частина)» (гіперконвергентний обчислювальний комплекс – для потреб Міністерства охорони здоров'я України)». Скаржник вважає, що Замовник порушив права та законні інтереси Скаржника неправомірними діями та рішенням, яке детально розглядаються у цій скарзі у відповідності та у порядку, передбаченому Статтею 18 Закону України «Про публічні закупівлі». А саме: 1) Замовник, своїм протокольним рішенням №174 та №178 від 17.08.2018 необґрунтовано допустив до аукціону пропозиції учасників ТОВ "ГЛОБАЛ ІНТЕГРЕЙШН ГРУП", ТОВ НАУКОВО-ВИРОБНИЧЕ ПІДПРИЄМСТВО "ВІТ" (Далі – «Учасники (1,2)»), незважаючи на грубі порушення ними вимог Тендерної Документації до технічних, якісних та кількісних характеристик предмету закупівлі. Підстави оскарження цього рішення Замовника, відповідні посилання та обґрунтування наявності порушених прав та охоронюваних законом інтересів Скаржника з приводу рішення Замовника детально розглянуто нижче, у розділах X-У цієї Скарги та Додатку №1 до цієї Скарги. 2) Замовник, своїм протокольним рішенням №173 від 17.08.2018 необґрунтовано відхилив пропозицію Скаржника, яка повністю задовольняла вимоги Тендерної Документації та Законодавства України. Підстави оскарження цього рішення Замовника, відповідні посилання та обґрунтування наявності порушених прав та охоронюваних законом інтересів Скаржника з приводу рішення Замовника детально розглянуто нижче, у розділі X цієї Скарги 3) Відповідно до Протокольних рішень Замовника №174 та №178 від 17.08.2018, Замовник допустив до аукціону учасників ТОВ "ГЛОБАЛ ІНТЕГРЕЙШН ГРУП", ТОВ НАУКОВО-ВИРОБНИЧЕ ПІДПРИЄМСТВО "ВІТ" (Далі – «Учасники (1,2)»), на підставі листа, якого він отримав від компанії ТОВ «ДЕЛЛ УКРАЇНА», та яке, за переконанням замовника містить доказ відповідності пропозицій Учасників (1,2) вимогам Тендерної Документації. Замовник не надав копії листа ТОВ «ДЕЛЛ УКРАЇНА», а лише процитував ряд аргументів та тверджень даного листа. Відповідно до детального аналізу цих аргументів та тверджень, який викладений у розділі ZZ цієї Скарги та Додатку №2 до цієї Скарги, лист ТОВ «ДЕЛЛ УКРАЇНА» містить неправдиву інформацію, та демонструє маніпулювання даними та фальсифікацію фактів. Цей факт, а також нехарактерний для ТОВ «ДЕЛЛ УКРАЇНА» стиль написання і застосування найменувань продуктів, та велика кількість граматичних помилок породжують мотивовані сумніви в авторстві та самому існуванні цього листа, з чого витікають обґрунтовані підозри у вчиненні фальсифікації даного листа і результатів торгів. Відповідно до викладеного вище та далі у цій Скарзі, Скаржник просить Орган Оскарження: 1) Прийняти скаргу до розгляду, розглянути її у присутності представника Скаржника 2) Зобов’язати Замовника відмінити протокольні рішення №174 та №178 від 17.08.2018 та відхилити пропозиції Учасників ТОВ "ГЛОБАЛ ІНТЕГРЕЙШН ГРУП", ТОВ НАУКОВО-ВИРОБНИЧЕ ПІДПРИЄМСТВО "ВІТ" (Далі – «Учасники (1,2)»), як такі, що не задовольняють вимогам Тендерної Документації 3) Зобов’язати Замовника відмінити протокольне рішення №173, як необґрунтоване, і допустити пропозицію Учасника до аукціону. 4) Зобов’язати Замовника невідкладно оприлюднити на порталі PROZORRO скан-копії листа від ТОВ «ДЕЛЛ Україна», на який посилається Замовник, та того офіційного листа-запита від Замовника на адресу ТОВ «ДЕЛЛ Україна», на який лист ТОВ «ДЕЛЛ Україна» є відповіддю. Повідомити листом через портал PROZORRO, яким чином було отримано листа від «ДЕЛЛ УКРАЇНА», від кого саме, та яким чином було встановлено правомочність особи, яка підписала листа. До Скарги Додаються: - Скарга Вих. №277 від 19.10.2018 ………….«Скарга.pdf» - Додаток №1 до Скарги……………………...«Скарга.Додаток №1.pdf» - Додаток №2 до Скарги……………………...«Скарга.Додаток №2.pdf» - Копія платіжного доручення про внесення плати за подання скарги №73 від 18 жовтня 2018 р -- «ПЛАТІЖНЕ ДОРУЧЕННЯ N73 від 18 жовтня 2018 р.pdf» - Копії протокольних рішень Замовника №173, №174, №178 від 17.08.2018 – «Протокол Глобал ІГ від 17.10.18 №174.pdf», «Протокол НВП ВІТ від 17.10.18 №178.pdf», «Протокол СІТІУС ПРО від 17.10.18 №173.pdf»

Що стосується вимог до загального ресурсу, який вимагає замовник, то вони детально та прозоро для всіх учасників сформульовані у тендерних вимогах та наданих роз’ясненнях. А саме: 1) Одиницею ресурсу є двохпроцесорний серверний вузел з заданою кількістю оперативної пам’яті, заданою потужністю процесорів та заданим дисковим простором, що дозволяє чітко та прозоро сформулювати та оцінити інші вимоги. двохпроцесорний серверний вузел з заданою кількістю оперативної пам’яті, може бути оденицею при умові одинакової кілбколсті вузлів у всіх учасників. Якщо згідгно умов відказостійкості учасник повинен пропонцувати 5ть серверів замість двох, використовуючи при цьому в 2 рази більше компонентів – це не є прозорою вимогою, а унікальною характеристикою виставляючою одного виробника в інших умовах ніж інших. Справедливо обчислювальні ресурси рівномірно росподілити між всіма апаратним компонентами в різних архітектурах відказостійкості. Чому так не робиться? Одиницею ресурсу в гіперконвергентній вахітектурі є не фізичний, а віртуальних процесор, не фізична а віртуальна память. Особливість гиперконвергентної архітектури є програмно визначеність ресурсів. В противному випадку можна пропонувати 2 сервера і систему збереження даних як альтернативу. Якщо ви ставите вимоги таким чином чи можливо, як альтернативу запропонувати 2 сервера + систему збереження даних? Якщо ні то чому? Таке рішення явно буде суттєво дешевшим, особливо приймаючи до уваги що до вашої системи окремо треба додавати систему резервного копіювання яка підтримує роботу з прикладними додатками.

Звертаємо Вашу увагу, що у відповідності до пункту технічного завдання: 4.1 Не менше ніж два вузли (сервери) в разі використання RAID контролера, не менше ніж три вузли в разі використання SAS/SATA HBA контролера Кожен вузел (сервер) повинен мати: - не менше ніж два дванадцятиядерних процесори з частотою не менше 2.6 ГГц, з не менше ніж 6-а каналами пам’яті DDR4, що оперують на швидкості не менше ніж 2666 MT/s. - не менше ніж 384ГБ оперативної пам'яті; - не менше ніж чотири порти Ethernet 25Гб/с або не менше двох портів Ethernet 40Гб/с - RAID контролер або SAS/SATA HBA контролера - відповідну кількість SSD дисків для забезпечення необхідного корисного об’єму даних. - не менше 6ТБ корисного простору системи збереження на флеш пам’яті (SSD), після урахування резервування, пов’язаного з забезпеченням високої доступності системи збереження даних, але без врахування будь-якої можливої компресії та дедуплікації. Використання RAID контролера та рішення на базі двох вузлів у випадку виходу з ладу одного з дисків на одному з вузлів гарантовано призведе до переходу всієї системи в режим READ ONLY до моменту перебудови RAID масиву і, відповідно, до відмови обслуговування задач замовника. Таке двовузлове рішення не є високонадійним на відміну від систем побудованих на НВА контролерах та стійких до втрати до 4-х дисків у тривузловій конфігурації. Окрім того, таке рішення доступне тільки у одного виробника (HPE), що ставить інших виробників у завідомо неконкурентні умови, особливо при зазначенні вимог по процесорам та пам’яті до КОЖНОГО з вузлів, а не системи в цілому. Таким чином відбувається дискримінація інших виробників, змушуючи їх пропонувати рішення з ресурсами на 33% більше, ніж рішення виробника НРЕ. Тому просимо: 1. Прибрати вимогу до кожного з вузлів і замінити їх на вимоги до системи в цілому на наступне: «не менше 36 корисних CPU ядер, та 650Гб Памяті, після урахування резервування, пов’язаного з забезпеченням роботи сторадж контролерів та інших системних вимог» 2. Прибрати умову «Не менше ніж два вузли (сервери) в разі використання RAID контролера», яка значно знижує надійність в цілому та дискримінує рішення більшості виробників (наприклад, таких як Dell, Cisco, Nutanix).

Це означає що віртуальна машина також не резервується відповідно протоколу API VMware VADP тобто відновлення роботи віртуальної машини запропонованим способом не підтримується самим VMware. Що передбачається робити, якщо віртуальна машина не стартує (синій екран)? Тобто платформа передбачає унікальний функціонал резервного копіювання, відновлення після якого не підтримуватиметься ні виробником віртуалізаціі ні виробником прикладних додатків і який допускає 10хв втрати інформації. Нема ніяких вимог по сумісності, а є прописана унікальна технологія яка не гарантує відновлення даних. Прокоментуйте будь ласка.

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

Система береться для роботи прикладних додатків чи умовних тестових віртуальних машин? Тут описується сценарій апаратного збою після втрати будь-якого з вузлів і ніяк не описані вимоги до відпрацювання сценарію відновлення після програмного збою. Наприклад Petia зашифрував всю інформацію на системі – нема резервної копії, або збій при оновленні ПО самої системи – дані з неї не можливо буде отримати. Причина – одна логічна структура розташування даних в рамках однієї системи при логічному збої системи приведе до втрати всіх даних. Можливість тримати дані на аналогічному комплексі у віддаленому ЦОД пердбачає що дані постійно синхронізуються тобто логічний збій на рівні додатку буде синхронізовано з другою системою –*не говорячи що 10Хв роботи додатку можна втратити при виключенні живлення бо вони в оперативній памяті. Нема логічної розвязки між апатаною платформою і самими даними прикладних додатків, так як не передбачене резервне копіювання на рівні прикладних додатків?