На пути к умной стойке: как мы тестировали метки для учета серверов в ЦОДе

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Привет, Хабр! Меня зовут Сергей, и в DataLine я занимаюсь совершенствованием систем мониторинга. Мы уже много рассказывали про мониторинг инженерной и сетевой инфраструктуры. Но помимо него есть еще и задача отслеживания ИТ-оборудования. 

Когда мы осуществляем мониторинг в дата-центре, важно знать, где находится каждый сервер и кому он принадлежит. Эта информация хранится в специальной системе для учета компонентов информационных систем, или Configuration management database (CMDB). Важно сразу обновлять данные по местонахождению серверов, иначе возникает проблема “серверов-призраков”, за которые никто не отвечает. 

Всю эту информацию можно вбивать в систему и руками. Но, когда речь идет уже о десятках тысяч стоек, хочется автоматизировать процесс. Мы развиваем нашу систему автоматизации и постоянно ищем, как ее улучшить. В воздухе давно витает идея “умной стойки”, которая сама знает, какое оборудование в каком юните у нее установлено. В нашем ЦОДе мы решили провести эксперимент и проверить несколько новых технологий для решения этой задачи. Покажу результаты этих экспериментов и буду рад обсудить, как эту задачу решает сообщество. 

Про задачи учета и текущие проблемы

Новое оборудование в дата-центре проходит стандартную цепочку постановки на учет. Для наших серверов и устройств клиента процесс немного отличается, но обобщенно все выглядит так. На новое ИТ-оборудование составляется акт приема-передачи. Дежурный инженер на приемке создает акт в CMDB: он присваивает ему номер и указывает свои Ф. И. О. Для клиентского оборудования заполняем название компании, Ф. И. О. ответственного лица от клиента и ссылку на договор. Для самого оборудования составляем таблицу с наименованием, типом оборудования и серийным номером. 

При заполнении таблицы каждому устройству присваивается штрихкод, он наклеивается сразу во время приемки. Теперь инженер может навести сканер, считать штрихкод и найти карточку сервера в CMDB.

Один из наших серверов с такой наклейкой.
Один из наших серверов с такой наклейкой.

Дальше устройству назначается стойка и юнит, в который его установят. Местоположение оборудования нужно сразу прописать в CMDB, но, к сожалению, так бывает не всегда. Иногда видим вот такую ситуацию:

Такое может быть, если устройство стоит в зоне временного хранения: не всегда оборудование устанавливается в стойку в тот же день, что и поступает в ЦОД. Также стойка и юнит не указываются, если оборудование уходит на склад и мы учитываем его в складской системе. Но иногда срабатывает и человеческий фактор: оборудование уже установили, а номер стойки указать забыли.

Вдобавок ко всему, наше оборудование может перемещаться из зала в зал, из стойки в стойку, между юнитами. Это надо учитывать и вносить изменения в CMDB. Если за этим не следить, в системе остаются “хвосты”. Бывает непонятно, где искать оборудование с пустыми или неактуальными строчками.  

Вот этот коммутатор и серверы сразу не найдем.
Вот этот коммутатор и серверы сразу не найдем.

Ситуацию исправляем с помощью регулярной инвентаризации, и в целом система со штрихкодами работает неплохо. Но в случае с тысячами клиентских стоек могут возникнуть трудности. Какие-то серверы устанавливаются в открытые стойки, их можно сразу просканировать и заполнить информацию. Но если все закрыто дверцей со СКУД, а сами стойки находятся внутри кейджа, быстро не посмотришь, нужны дополнительные действия. Также после установки сервера штрихкод могут загородить проводами или чем-то еще. Тогда даже в открытой стойке считать его довольно сложно. 

Чтобы записи в базе данных учета оборудования велись правильно и обновлялись своевременно, есть два варианта развития: 

  • делать более четкие регламенты, инструкции для инженеров и контролировать выполнение за счет развития управленческих инструментов; 

  • попытаться это автоматизировать.

Сейчас первый вариант у нас реализован довольно неплохо. Мы решили протестировать варианты развития по второму пути. 

RFID

Если в поисковике вбить ”Data center asset management”, то выпадет куча ссылок от зарубежных компаний, которые предлагают учитывать оборудование в стойках с помощью меток RFID. Подробности решения как всегда не описываются – есть только типовые рекламные презентации, сулящие экономию времени, средств и т. д. Мы начали тестирование с них. 

Принцип действия технологии. Кратко напомню, как RFID работает в этом кейсе. В нашем случае мы закрепляли  на оборудовании метки UHF RFID:

Справа и слева – антенна, в середине стоит маленький чип.
Справа и слева – антенна, в середине стоит маленький чип.

Метки работают без батареек благодаря явлению электромагнитной индукции. Специальный RFID-ридер облучает их электромагнитным излучением, и ЭДС индукции наводится на метке благодаря встроенной антенне. Чип на метке активируется и возвращает ридеру информацию с идентификатором метки. Как раз таким способом “чипированный” сервер может сообщить стойке: “я такой-то и нахожусь здесь”. 

С использованием RFID нам не нужна прямая видимость меток. Это существенный плюс по сравнению с наклеиванием штрихкодов.

Подготовка к тестированию. Мы спланировали конфигурацию с RFID-ридерами, к которым можно подключить несколько антенн для приема сигнала от меток. В каждой стойке ставим свою антенну с уникальным идентификатором, который привязан к этой стойке. На фронтальной панели единицы оборудования закрепляем RFID-метку со своим идентификатором. 

Мы предполагали, что сможем определить ближайшую антенну в стойке по максимальному уровню сигнала от метки. В ходе теста хотели отследить у каждой метки показатель уровня принимаемого сигнала, или RSSI, и убедиться в своей гипотезе.

Тест считали успешным, если получится определить стойку, в которой находится единица оборудования. Об определении оборудования с точностью до юнита не мечтали. 

Для эксперимента взяли оборудование, которое доступно на AliExpress. 

  • 4-портовый ридер RFID UHF R2000 (CF-RU6403). Цена: US $274.55.

  • В качестве ПО для тестирования использовали “коробочное” CF-RU6403 SDK.

  • Пассивные RFID UHF EPC-метки. Цена: US $1.

Для выбранной конфигурации решили проверить несколько типов антенн и сравнить точность считывания: 

  • Стандартная антенна к выбранному ридеру. Цена: US $37.

  • GSM-антенна. Цена: US $3.

  • Самодельная антенна-диполь. Цена в пределах US $1.

Тест № 1. Стандартная антенна. Начинаем монтаж для первого эксперимента: антенну фиксируем на двери и размещаем 5 меток на фронтальных панелях оборудования, пока без наклеивания: 

3 метки в середине, одна наверху и одна – в самом низу.
3 метки в середине, одна наверху и одна – в самом низу.

Запускаем ПО – вот как видны эти метки. 

Видим только четыре из пяти: самая нижняя метка не считалась. Возможно, одной антенны на шкаф недостаточно, или выступающие элементы оборудования мешают распространению электромагнитного излучения.

Попробовали расположить метки горизонтально на верхних крышках оборудования. Так метки тоже читаются плохо: до них просто не доходит излучение.

Сразу же обнаружили проблему с наклеиванием меток на фронтальных панелях оборудования. Как правило, спереди на серверном оборудовании размещаются корзины для дисков, кнопки и индикаторы, на сетевом оборудовании спереди располагаются порты – свободных мест практически нет. Попробуем по-другому.

Тест № 2. GSM-антенна. В этот раз метки и антенну расположим вот так:

Во время теста смотрим на значения уровня приема RSSI в dBm, в зависимости от мощности излучателя. Результаты такие:

Мощность излучателя

Метка

13 dBm

14 dBm

15 dBm

16 dBm

18 dBm

20 dBm

20000A

63

65

60

56

63

62

20000B

-

-

-

-

58

62

20000C

82

84

68

64

70

74

20000D

73

75

79

54

81

80

20000E

71

72

72

-

74

76

20000F

-

-

-

-

-

45

Стойка слева

2000008

-

-

55

-

57

-

2000010

-

-

51

-

51

54

Как видим, много прочерков – эти метки не видны. Как бы мы ни меняли положение антенны в этом тесте, не все метки в стойке считываются при малых мощностях сигнала от ридера. При высоких мощностях ”захватываются” метки из соседней стойки. При этом уровень приема для меток по соседству выше, чем для некоторых “своих” меток. То есть определить метки на уровне стойки не получается. 

Тест № 3. Самодельный полуволновой диполь. Попробуем еще одну антенну, закрепим ее вот так: 

Снова смотрим уровень приема RSSI.  Результаты:

Мощность излучателя

Метка

15 dBm

16 dBm

20 dBm

25 dBm

30 dBm

20000A

-

-

-

-

-

20000B

-

-

49

49

64

20000C

48

52

50

55

60

20000D

57

57

59

60

-

20000E

-

-

-

-

-

20000F

57

59

61

65

74

Стойка слева 

2000008

-

-

-

-

-

2000010

-

-

50

-

-

2000011

-

46

50

56

-

Между 25 и 30 dBm чтение меток становится хуже. На меньшей мощности снова захватываются метки из соседней стойки. Вертикальное расположение антенны тоже не улучшило картины.

Возможно, результаты были бы лучше, если бы антенна представляла собой своеобразный занавес, который покрывает всю площадь дверцы. В теории мы представляли вариант, что RFID-ридер может ездить вместе с антенной по специальным рельсам вдоль ряда стоек и покрывать всю фронтальную поверхность стоек. Но пока мы подобные решения не тестировали.

Технология BLE

Помимо RFID нам могла помочь технология bluetooth low energy, или BLE. Ее применяют в автомобильных сигнализациях, а также в различных датчиках для отслеживания передвижения объектов, температуры, освещенности и вибрации. 

Принцип действия технологии. В качестве считывающего устройства может выступать не только антенна, но и смартфон, а подает сигналы гаджет с батарейкой. Для теста на обнаружение серверов мы в качестве такого гаджета использовали BLE-метки, или маяки. Их тоже планировали считывать с помощью специального ридера с антенной. Маяки выглядят так:

Каждая такая метка отправляет сообщение раз в 10 минут.

Подготовка к тесту. Для тестирования мы взяли несколько вариантов меток и ридеров у одной знакомой отечественной компании. На старте сразу выявили одну бракованную метку: возможно, в нее забыли установить батарейку.

Метки и ридеры разместили в четырех стойках с дисковыми массивами. Стойки практически идеальные с точки зрения однородности оборудования и выступающих элементов. Дверцы стоек заземлены – это предотвращает распространение электромагнитного излучения от меток наружу.

Каждой стойке соответствовал свой ID установленного ридера:

№ стойки

ID ридера в стойке

1

891

2

1583

3

1632

4

6143

В план тестирования включили такие этапы:

  1. Тест на стабильность чтения при закрытых дверях стоек.

  2. Тест на перестановку меток. Метки произвольным образом переставляли и закрывали дверцы стоек.

  3. Работа с полностью заполненной стойкой –  все 38 меток устанавливали в одну стойку.

  4. Тест при открывании дверей стоек.

  5. Тест на стабильность работы в стойках без дверей. 

В каждом тесте определяли следующие показатели:

  • процент ошибок в определении с точностью до стойки;

  • процент ошибок в определении с точностью до соседней стойки;

  • процент нестабильно определяемых меток (минимум одна ошибка в определении за время теста).

Как смотрели эти показатели, покажу на примере первого теста. 

Тест № 1. Cтабильность чтения при закрытых дверях стоек. Технология BLE более “дальнобойная”. Место расположения метки определяется по максимальному значению RSSI. В итоговую таблицу сразу заносим ID того ридера, который показывает максимальное значение, и проверяем совпадение с реальной картиной:

Tag ID

ID ридера в стойке

ID ридера с max.RSSI

Результат

1

03027136-727c-4c6e-924a-012ee05ffa0b

1632

1583

ERROR

2

076243f5-b12e-4bf4-a510-9dd0f2380696

6143

6143

OK

3

081cec6d-e058-4607-b4e7-a0bb4b614fd2

6143

6143

OK

4

09a14423-142e-4d2b-92b9-eec610be6f76

1632

1632

OK

5

0e23455f-9812-4a1c-a490-5f81d06a3a40

6143

6143

OK

6

0fd874d7-9c53-44d0-b54d-87e5bf6ff407

1583

891

ERROR

7

20df07a2-346c-47e2-98d7-ab95c79a0fd8

891

891

OK

8

27fa42e5-c842-4fa0-9430-533564c5d2bd

1583

1583

OK

9

305bfdcf-9d7b-4623-85db-786e5bbe1e5e

1583

891

ERROR

10

31d1c178-5e84-43af-b151-04eb47f2c23a

891

891

OK

11

4452725a-6481-43c4-ac12-11ae805e7269

1583

1583

OK

12

46ce9c03-fd4d-4877-b254-ab2e2b3a39e7

1583

1583

OK

13

49403290-3d68-45bb-8daa-ca11fec40784

891

891

OK

14

4d2ee2b9-349d-464d-a03b-052653207d0f

6143

6143

OK

15

5543038e-682d-492a-9dd7-f9665d76c88a

1583

1583

OK

16

593573d1-96da-49f7-85d4-2c886b61e694

1583

1583

OK

17

5edc8736-1a7e-4556-b189-32bfd09f8150

6143

6143

OK

18

6b14dd3b-2d1a-4dad-abed-7b261936fae2

891

891

OK

19

6f1aed32-34b8-414a-a2af-32d78182aeb9

1632

1632

OK

20

7dff4df1-0749-4b9d-81ef-7bd3e408e046

1632

1632

OK

21

8454d30f-e2ea-44fe-acd5-e68087849547

1583

1583

OK

22

86090904-1521-4565-9d93-f98cd8766513

1632

 ERROR 

ERROR 

23

87d4a663-2c52-4ac1-9124-7218ebcbc19b

891

891

OK

24

970a43fa-d21f-4def-b3cf-e77dc2e4e758

6143

6143

OK

25

a34f4e16-f7ec-4993-8fa4-7af8058e10c3

891

891

OK

26

a4cb5650-b7bb-4888-99ed-91066080ae1d

1632

1632

OK

27

b5061940-95f1-450f-8a54-7a3061bdd7d6

891

891

OK

28

bc7e45c8-9fe2-458a-9be2-527863e928a0

891

891

OK

29

c808334f-4549-4abe-98d4-a78ca132ece4

6143

6143

OK

30

c816484e-d7c2-4ca6-8369-528c67546662

1632

1632

OK

31

ce169bb2-9356-4240-a191-b4a87b2abd7b

891

891

OK

32

d08d6816-bebd-4f10-a661-0761641ca448

6143

6143

OK

33

d29fc25d-a096-4cf7-b076-991c0adb613d

6143

6143

OK

34

dbb80eb0-41ba-4396-bde4-e94b5cfcb8af

6143

6143

OK

35

ddf3ccd7-1d54-4eca-8ab5-e26e52c4ac62

891

891

OK

36

e49c683d-48aa-4655-99c7-c402c3dee175

1632

6143

ERROR

37

e8837b76-e92a-4bc4-bc97-34cea0b0321f

891

891

OK

38

f09ce83d-bb2b-4e1e-a9d0-9106d6e5bca7

1583

1583

OK

39

fcb2affb-4e45-481e-8275-08a60efa926c

1632

1583

ERROR

Из таблицы видно 5 ошибок позиционирования и еще одну ошибку из-за вышедшей из строя метки (#22). Все ошибки позиционирования одинаковые: метки считывают ридеры из соседних стоек. Соответственно, процент ошибок в определении с точностью до соседней стойки был нулевым. Процент ошибок в определении с точностью до стойки равен 5/38*100% = 13%.

Что касается стабильности определения меток, то особой флуктуации не видно. В этом тесте только 3 метки незначительно “прыгают” от ридера к ридеру. В ячейках указано количество считываний метки ридером за 2 часа:

№ метки

Tag ID2

163

6143

1583

891

1

03027136-727c-4c6e-924a-012ee05ffa0b

10

2

076243f5-b12e-4bf4-a510-9dd0f2380696

10

3

081cec6d-e058-4607-b4e7-a0bb4b614fd2

10

4

09a14423-142e-4d2b-92b9-eec610be6f76

10

5

0e23455f-9812-4a1c-a490-5f81d06a3a40

10

6

0fd874d7-9c53-44d0-b54d-87e5bf6ff407

1

9

7

20df07a2-346c-47e2-98d7-ab95c79a0fd8

10

8

27fa42e5-c842-4fa0-9430-533564c5d2bd

10

9

305bfdcf-9d7b-4623-85db-786e5bbe1e5e

10

10

31d1c178-5e84-43af-b151-04eb47f2c23a

10

11

4452725a-6481-43c4-ac12-11ae805e7269

10

12

46ce9c03-fd4d-4877-b254-ab2e2b3a39e7

10

13

49403290-3d68-45bb-8daa-ca11fec40784

 

 

2

10

14

4d2ee2b9-349d-464d-a03b-052653207d0f

10

15

5543038e-682d-492a-9dd7-f9665d76c88a

10

16

593573d1-96da-49f7-85d4-2c886b61e694

10

17

5edc8736-1a7e-4556-b189-32bfd09f8150

2

10

 

 

18

6b14dd3b-2d1a-4dad-abed-7b261936fae2

10

19

6f1aed32-34b8-414a-a2af-32d78182aeb9

10

20

7dff4df1-0749-4b9d-81ef-7bd3e408e046

10

21

8454d30f-e2ea-44fe-acd5-e68087849547

10

22

87d4a663-2c52-4ac1-9124-7218ebcbc19b

10

23

970a43fa-d21f-4def-b3cf-e77dc2e4e758

10

24

a34f4e16-f7ec-4993-8fa4-7af8058e10c3

10

25

a4cb5650-b7bb-4888-99ed-91066080ae1d

10

26

b5061940-95f1-450f-8a54-7a3061bdd7d6

10

27

bc7e45c8-9fe2-458a-9be2-527863e928a0

10

28

c808334f-4549-4abe-98d4-a78ca132ece4

10

29

c816484e-d7c2-4ca6-8369-528c67546662

8

 

2

 

30

ce169bb2-9356-4240-a191-b4a87b2abd7b

10

31

d08d6816-bebd-4f10-a661-0761641ca448

10

32

d29fc25d-a096-4cf7-b076-991c0adb613d

10

33

dbb80eb0-41ba-4396-bde4-e94b5cfcb8af

10

34

ddf3ccd7-1d54-4eca-8ab5-e26e52c4ac62

10

35

e49c683d-48aa-4655-99c7-c402c3dee175

10

36

e8837b76-e92a-4bc4-bc97-34cea0b0321f

10

37

f09ce83d-bb2b-4e1e-a9d0-9106d6e5bca7

10

38

fcb2affb-4e45-481e-8275-08a60efa926c

10

Тест № 2. Перестановка меток. Переставим метки. И снова процент ошибок в определении с точностью до стойки – 13% (5 из 38). Процент нестабильно определяемых меток – 13% (5 из 38).

Тест № 3. Работа с полностью заполненной стойкой. Процент ошибок в определении с точностью до стойки составляет 28,9% (11 из 38). Процент нестабильно определяемых меток – 18,4% (7 из 38).

Тест № 4. Открывание дверей стоек. Как только начинаем открывать двери стоек, сразу же считываются метки из соседних стоек. Было 22 ошибки определения с точностью до стойки (57%) и 3 ошибки определения с точностью до соседней стойки (7,8%).

Тест № 5. Стабильность работы в стойках без дверей. Когда дверцы полностью демонтировали, было уже 12 ошибок определения с точностью до соседней стойки (31%).

На этом мы закончили. Провели много испытаний и так, и сяк. Все равно процент ошибок для нас очень высокий – при ручной инвентаризации он значительно ниже. Планировали еще использовать ридер с двумя или несколькими антеннами в стойке, чтобы повысить точность определения местоположения меток, но подобный ридер нам так и не удалось заполучить.

Какие еще есть варианты решения

Перспективной технологией для решения задачи может стать компьютерное зрение, как это реализовано в супермаркетах. Сейчас алгоритмы хорошо справляются с тем, чтобы распознавать товары на полках. 

На месте бутылок и банок можно легко представить себе единицы оборудования. Фотографируем фронтальную часть стойки и  распознаем оборудование или, по крайней мере, считываем штрихкоды/QR-коды. 

Но пока на рынке мы не видели ничего подобного для ЦОДов. Для этого понадобится создать базу фотографий наших стоек и обучить модель на этих данных. Сам процесс обучения выглядит достаточно просто. Другое дело – точность. 

Еще одна возможная проблема – как добраться до серверов за дверцами. Тут мы видим два варианта. Первый – устанавливать камеры стационарно в коридорах залов, но регулярно открывать все стойки. Второй – оставить фотографирование заботой инженера, но само распознавание и занесение в CMDB оставить ИИ.

Сейчас в этом процессе считыватели и наклейки нам неплохо помогают. Все остальные решения – это эксперимент, но мы продолжаем искать варианты. Буду рад услышать о вашем опыте: как подобную задачу решали вы?

Источник: https://habr.com/ru/company/dataline/blog/552508/


Интересные статьи

Интересные статьи

Иногда можно слышать о том, что архитектура Unix не имеет существенных недостатков. Особенно — если говорить о «чистой» архитектуре Research Unix (которая существовала до того, как те, кт...
Добро пожаловать в эпоху RISC-V! Решения на базе открытого стандарта системы команд RISC-V всё чаще появляются на рынке. Уже в серийном производстве микроконтроллеры от китайских колл...
Продолжая цикл заметок про реальные проблемы в Data Science, мы сегодня разберемся с живой задачей и посмотрим, какие проблемы нас ждут в пути. Например, помимо Data Science, я ...
На Хабре сегодня уже звучали хэллоуинские байки. А как насчет конкурса на самую страшную историю? Пускай она начинается так: Пустой ночной офис отзывался холодом. Шум серверов и ветер в...
Как широко известно, с 1 января 2017 года наступает три важных события в жизни интернет-магазинов.