Вантажівки рефрижератори в хмарі

В цій статті хочемо поділитися з вами історією створення базового прототипу шлюзу і його перенесення на хмарну платформу Microsoft Azure з використанням моделі Software as a Service (SaaS).



Для того, щоб було зрозуміло, про що нижче піде мова — невеличка довідка:
  • Кварта Технології — постачальник рішень в області базової ІТ-інфраструктури і лідер російського ІТ-ринку в області повної інформаційної та технічної підтримки технологій для вбудованих систем на базі Microsoft Windows Embedded.
  • ТехноКом працює в області розробки і виробництва систем ГЛОНАСС/GPS супутникового моніторингу транспорту, персоналу, датчиків контролю палива та програмного забезпечення для будь-яких компаній і галузей транспорту, промисловості і сільського господарства. Найвідоміший продукт компанії навігаційні термінали серії «АвтоГРАФ».
  • iQFreeze — рішення від Кварта Технології, яка збирає, обробляє і передає інформацію про стан вантажу і транспорту в реальному часі.
Створення базового прототипу шлюзу
Система АвтоГРАФ являє собою класичне клієнт-серверний додаток з можливостями доступу до даних і аналітики. Її поточна архітектура обумовлює високу вартість масштабування. Саме тому ключовою ідеєю для спільної роботи стала спроба переосмислити архітектуру, привівши її до моделі SaaS для вирішення проблем з масштабністю і створення інноваційного пропозиції для ринку.



Перед початком проекту було очевидно, що проведення технологічного взаємодії в парадигмі Інтернету Речей може стати досить складним завданням, так як включає в себе, крім інтеграції сервісів Azure вже існуюче ПЗ, ще й питання, що стосуються отримання даних з встановленого на транспорті обладнання – терміналів супутникового моніторингу транспорту АвтоГРАФ (далі по тексту «термінали СМТ»). І тільки відповідна підготовка значно спрощує завдання. Тому підготовка почалася приблизно за місяць до початку самого заходу. В результаті були обговорені кілька ключових питань, які наведені нижче з відповідями на них.

Запущена система в експлуатацію? Який стан мають пристрої, що вони вміють робити і що не вміють?
На сьогодні система працює кілька років. Так як вона була призначена для використання з транспортом різних виробників/партнерів, є відмінності в обладнанні. Майже всі пристрої схожі тільки в одному — зміна прошивки навіть на невеликій їх кількості не представляється можливим через їх продуктивної роботи в середовищі. З цієї причини використання моделі Field Gateway (розміщення або установка шлюзу близько до пристроїв) неможливо.

Який протокол використовують пристрої для зв'язку з серверною частиною?
Бінарний протокол власної розробки компанії ТехноКом.

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

чи Потрібно керувати пристроями віддалено?
Можливо, в майбутньому, але не зараз.

У процесі планування було вирішено розширити список завдань в зв'язку з додаванням до системи компонентів для обробки зібраних даних. Відповідно, поточна монолітна архітектура повинна була бути розбита на модулі. Був організований надходить потік даних з АвтоГРАФа, тому питання, що стосуються емуляції пристроїв, були закриті.

Для хостингу шлюзу, слухаючого TCP-порт і передає дані в підсистему обробки даних, був обраний хмарний сервіс Microsoft Azure Cloud Services.

Для того, щоб реалізувати прототип у команди було 5 годин і 3 розробника на 6 завдань:
  1. Оцінити поточну архітектуру й переосмислити її, використовуючи PaaS.
  2. Реалізувати тестовий шлюз (консольний додаток) для перевірки роботи.
  3. Оцінити наявні опції для створення хмарного шлюзу (наприклад, Azure IoT Gateway, Cloud Services і так далі).
  4. Провести міграцію шлюзу в хмару.
  5. З'єднати шлюз з підсистемою обробки даних (тобто, написати код для цього).
  6. Додати прототип можливості моніторингу з допомогою Application Insights.
Спочатку вирішили зосередитися на питанні про те, як розбити монолітне додаток на компоненти.

Архітектура до

Стара архітектура являла собою класичну двухзвенную архітектуру «Клієнт — сервер», монолітне додаток, написаний на C++ і працює в середовищі Windows Server. Його робота полягала в тому, щоб приймати пакети даних від моніторингової системи, встановленої на пристроях, зберігати ці пакети в локальному сховищі і бути фронтендом для доступу до даних для зовнішніх користувачів. Всередині програми було кілька модулів: мережевий, зберігання даних, розшифрування даних і роботи з базою даних.

Дані між сервером і пристроями передавалися по проприетарному бінарним TCP-протоколу. Для підключення клієнт відсилає handshake-пакет, сервер повинен був відповісти на нього пакетом підтвердження.



У своїй роботі програма використала набір системних викликів Win32API. Дані зберігаються у бінарній формі у вигляді файлів.

Проблема масштабування подібної полягає в обмеженості способів реалізації: збільшення ресурсів сервера/додавання нового та налаштування балансувальника навантаження і виконання інших завдань.

Архітектура після

Після застосування нової архітектури додаток втратило свою актуальність, так як по суті, воно було шлюзом і виконувало декілька службових завдань (наприклад, щодо збереження даних без їх зміни). У новій архітектурі все це було замінено на сервіси Azure (розробники оцінювали, яку опцію краще вибрати: Azure IoT Gateway або написаний власноруч шлюз; і вибрали другий варіант з хостингом в Azure Cloud Services).



Принципи функціонування нової системи аналогічні принципам роботи старою, проте надають додаткові можливості масштабування (у тому числі автоматичного) і знімають інфраструктурні завдання, наприклад, по налаштуванню балансувальника навантаження. Кілька примірників (инстансов) Cloud Service зі шлюзом прослуховують спеціальний порт, підключають пристрої і передають дані в підсистему їх обробки.

Перенесення прототипу на хмарну платформу Microsoft Azure з використанням моделі Software as a Service (SaaS)
Важливо починати з невеликих кроків і не реалізовувати всі відразу в хмарі. Хмара має свої переваги і особливості, які можуть ускладнити прототипування (наприклад, відкриття портів, налагодження віддаленого проекту, розгортання і так далі). Тому в даному випадку перший етап розробки полягав у створенні локальної версії шлюзу:
  • Шлюз слухає TCP-порт і при отриманні handshake-пакету від пристрою ініціює з'єднання.
  • Шлюз відповідає ACK-пакетом і встановлює підключення. При отриманні пакетів даних, згідно специфікації, ці пакети розкладаються на готовий контент.
  • Шлюз пересилає дані далі.
У процесі створення прототипу виникла проблема — розробники працювали в офісі Microsoft, де мережний периметр безпеки має певну кількість різного роду політик, що могло призвести до ускладнення прототипування локального шлюзу. Так як можливості змінювати політики не було, команда скористалася ngrok, який дозволяє створити безпечний тунель на localhost.

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

Запис на локальне сховище Cloud Service

Звичайно, порівняно з локальним зберіганням даних на инстансе, в Azure є кращі способи зберігання інформації, однак стара архітектура мала локальне зберігання, тому необхідно було перевірити можлива робота системи в цьому режимі. За замовчуванням, всі, що працює в Cloud Service, не має доступу до файлової системи — тобто просто так взяти і записати інформацію в c:/temp не вийде. Так як це PaaS, необхідно налаштувати спеціальне простір під назвою Local Storage в конфігурації хмарного сервісу та встановити прапор cleanOnRoleRecycle, який з певною мірою впевненості гарантує, що інформація з локального сховища не буде видалена при перезапуску ролі. Нижче код, який був використаний для вирішення даної задачі.
const string azureLocalResourceNameFromServicedefinition = "LocalStorage1";

var azureLocalResource = RoleEnvironment.GetLocalResource(azureLocalResourceNameFromServicedefinition);

var filepath = azureLocalResource.RootPath + "telemetry.txt";

Byte[] bytes = new Byte[514];
String data = null;

while (true)
{
TcpClient client = server.AcceptTcpClient();
data = null;
int i;
NetworkStream stream = client.GetStream();

while ((i = stream.Read(bytes, 0, bytes.Length)) != 0)
{
...
System.IO.File.AppendAllText(filepath, BitConverter.ToString(bytes));
...
}

client.Close();
}

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

Отримання адреси і порту инстанса

Для того, щоб в runtime отримати дані, необхідно визначити Endpoint всередині конфігурації хмарного сервісу та звернутися до нього в коді.



IPEndPoint instEndpoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints\["TCPEndpoint"\].IPEndpoint;
IPAddress localAddr = IPAddress.Parse(instEndpoint.Address.ToString());
TcpListener server = new TcpListener(localAddr, instEndpoint.Port);

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

Отже, локальний шлюз запущений і протестований на Cloud Services (який можна емулювати локально), тепер настала черга розгорнути проект в хмару. Інструментарій Visual Studio дозволяє робити це в кілька кліків.



Питання подальшої пересилки даних з инстанса шлюзу був успішно закритий використанням офіційних семплів коду.

Висновки
При плануванні команда турбувалася про те, що одного дня буде недостатньо для того, щоб розробити працюючий прототип системи, особливо в умовах наявності різноманітних середовищ, пристроїв і вимог (застарілі пристрої, протоколи, монолітне програма на С++). Дещо справді не встигли зробити, але базовий прототип був створений і працював.

Використання для такого роду завдань моделі PaaS є відмінним способом:
  • Швидкого прототипування рішення.
  • Використання сервісів і налаштувань для того, щоб зробити рішення гнучким масштабованим і з самого початку.
За кілька годин вдалося створити основу для розробки end-to-end рішення в парадигмі IoT з використанням реальних даних. У планах на майбутнє — використання машинного навчання для вилучення більшої користі з даних, міграція на новий протокол і тестування рішення на платформі Microsoft Service Fabric.

Дякуємо за участь у створенні матеріалу Олександра Білоцерківського і команду Кварта Технології.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.