Русский
Русский
English
Статистика
Реклама

Блог компании ua-hosting.company

Предсказание будущего нейрокомпьютерная модель распознавания речи

01.07.2020 10:24:00 | Автор: admin


Что есть речь человека? Это слова, комбинации которых позволяют выразить ту или иную информацию. Возникает вопрос, откуда мы знаем, когда заканчивается одно слово и начинается другое? Вопрос довольно странный, подумают многие, ведь мы с рождения слышим речь окружающих людей, учимся говорить, писать и читать. Накопленный багаж лингвистических знаний, конечно, играет важную роль, но помимо этого есть и нейронные сети головного мозга, разделяющие поток речи на составляющие слова и/или слоги. Сегодня мы с вами познакомимся с исследованием, в котором ученые из Женевского университета (Швейцария) создали нейрокомпьютерную модель расшифровки речи за счет предсказания слов и слогов. Какие мозговые процессы стали основой модели, что подразумевается под громким словом предсказание, и насколько эффективна созданная модель? Ответы на эти вопросы ждут нас в докладе ученых. Поехали.

Основа исследования


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

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

В частности распознавание речи связывают с комбинацией тета и гамма колебаний, поскольку она позволяет иерархически координировать кодирование фонем в слогах без предварительного знания их длительности и временного возникновения, т.е. восходящая обработка* в реальном времени.
Восходящая обработка* (bottom-up) тип обработки информации, основанный на поступлении данных из среды для формирования восприятия.
Естественное распознавание речи также сильно зависит от контекстных сигналов, которые позволяют предвидеть содержание и временную структуру речевого сигнала. Ранее проведенные исследования показали, что во время восприятия непрерывной речи важную роль играет именно механизм прогнозирования. Этот процесс связывают с бета колебаниями.

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

Другими словами, мозг всегда учится чему-то новому, постоянно обновляя модель окружающего мира. Этот процесс считается критически важным в обработке речевых сигналов.

Ученые отмечают, что во многих теоретических исследованиях поддерживаются как восходящий, так и нисходящий* подходы к обработке речи.
Нисходящая обработка* (top-down) разбор системы на составляющие для получения представления о ее композиционных подсистемах способом обратной инженерии.
Разработанная ранее нейрокомпьютерная модель, включающая соединение реалистичных тета- и гамма- возбуждающих/тормозных сетей, была способна предварительно обрабатывать речь таким образом, чтобы затем ее можно было правильно декодировать.

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

Следовательно, обе модели работали, просто в разных направлениях. Одна была сфокусирована на аспекте анализа речи в режиме реального времени, а другая на распознавании изолированных речевых сегментов (анализ не требуется).

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

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

Они разработали нейрокомпьютерную модель Precoss (от predictive coding and oscillations for speech), основанную на структуре предиктивного кодирования, в которую добавили тета- и гамма-колебательные функции, чтобы справиться с непрерывной природой естественной речи.

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

Архитектура Precoss модели


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

Разработанная модель четко отделяет чтои когда. Что относится к идентичности слога и его спектральному представлению (не временная, но упорядоченная последовательность спектральных векторов); когда относится к предсказанию времени и продолжительности слогов.

В результате прогнозы принимают две формы: начало слога, сигнализируемое тета-модулем; и длительность слога, сигнализируемая экзогенными/эндогенными тета-колебаниями, которые задают длительность последовательности единиц с гамма-синхронизацией (схема ниже).


Изображение 1

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

  • тета-колебание;
  • блок медленной амплитудной модуляции в тета-модуле;
  • пул слоговых единиц (столько слогов, сколько присутствует в естественном вводном предложении, т.е. от 4 до 25);
  • банк из восьми гамма-единиц в спектротемпоральном модуле.

Вместе единицы слогов и гамма-колебания генерируют нисходящие прогнозы относительно входной спектрограммы. Каждая из восьми гамма-единиц представляет собой фазу в слоге; они активируются последовательно, и вся последовательность активации повторяется. Следовательно, каждая единица слога связана с последовательностью из восьми векторов (по одному на гамма-единицу) с шестью компонентами каждый (по одному на частотный канал). Акустическая спектрограмма отдельного слога генерируется путем активации соответствующей единицы слога на протяжении всей продолжительности слога.

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

Наконец, накопленные данные о предполагаемом слоге должны быть удалены перед обработкой следующего слога. Для этого последний (восьмой) гамма-блок, который кодирует последнюю часть слога, сбрасывает все слоговые единицы до общего низкого уровня активации, что позволяет собирать новые свидетельства.


Изображение 2

Производительность модели зависит от того, совпадает ли гамма-последовательность с началом слога, и соответствует ли ее длительность продолжительности слога (50600 мс, среднее = 182 мс).

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

Результаты моделирования


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

Эта тета-гамма связь обеспечивает временное выравнивание внутренних сгенерированных предсказаний с границами слога, обнаруженными по входным данным (вариант A на изображении 3).


Изображение 3

Для оценки релевантности синхронизации слогов на основе медленной амплитудной модуляции было проведено сравнение модели А с вариантом В, в котором тета-активность не моделируется колебаниями, а возникает из самоповторения гамма-последовательности.

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

Чтобы более точно оценить специфические эффекты тета-гаммы соединения и сброса накопленных данных в слоговых единицах, были сделаны дополнительные варианты предыдущих моделей A и B.

Варианты C и D отличались отсутствием предпочтительной скорости гамма-излучения. Варианты E и F дополнительно отличались от вариантов C и D отсутствием сброса накопленных данных о слогах.

Из всех вариантов модели только A имеет истинную тета-гамма связь, где гамма-активность определяется тета-модулем, тогда как в В модели гамма-скорость устанавливается эндогенно.

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

Между вариантами присутствовали значительные отличия. По сравнению с моделями A и B, производительность была значительно ниже в моделях E и F (в среднем на 23%) и C и D (на 15%). Это указывает на то, что стирание накопленных данных о предыдущем слоге перед обработкой нового слога является критически важным фактором кодирования слогового потока в естественной речи.

Сравнение вариантов A и B с вариантами C и D показало, что тета-гамма связь, будь то стимульная (A) или эндогенная (B), значительно улучшает производительность модели (в среднем на 8.6%).

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

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

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

Чтобы лучше понять столь неожиданный поворот событий, ученые провели еще один ряд экспериментов, но со сжатыми речевыми сигналами (х2 и х3). Как показывают поведенческие исследования, понимание речи, сжатой в х2 раза, практически не меняется, но сильно падает при сжатии в 3 раза.

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


Изображение 4

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

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

Способность модели точно распознавать слоги во входном предложении не учитывает переменную сложность различных сравниваемых моделей. Потому была проведена оценка байесовского информационного критерия (BIC) для каждой модели. Данный критерий количественно определяет компромисс между точностью и сложностью модели (изображение 5).


Изображение 5

Вариант А показал самые высокие значения BIC. Ранее проведенное сравнение моделей А и В не могло точно различить их производительность. Однако благодаря критерию BIC стало очевидно, что вариант A обеспечивает более уверенное распознавание слогов, чем модель без тета-колебаний, управляемых стимулом (модель В).

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

Эпилог


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

По сути своей, разработанная модель имитировала работу мозга человека. Звук, поступающий в систему, модулировался тета волной, напоминающей активность нейронов. Это позволяет определить границы слогов. Далее более быстрые гамма-волны помогают кодировать слог. В процессе система предлагает возможные варианты слогов и корректирует выбор при необходимости. Перескакивая между первым и вторым уровнями (тета и гамма), система обнаруживает правильный вариант слога, а потом обнуляется, чтобы начать процесс заново для следующего слога.

Во время практических испытаний удалось успешно расшифровать 2888 слогов (220 предложений естественной речи, использовался английский язык).

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

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

Благодарю за внимание, оставайтесь любопытствующими и хорошей всем рабочей недели, ребята. :)

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Конференция DEVOXX UK. Выбираем фреймворк Docker Swarm, Kubernetes или Mesos. Часть 2

14.06.2020 10:15:40 | Автор: admin
Docker Swarm, Kubernetes и Mesos являются наиболее популярными фреймворками для оркестровки контейнеров. В своем выступлении Арун Гупта сравнивает следующие аспекты работы Docker, Swarm, и Kubernetes:

  • Локальный девелопмент.
  • Функции развертывания.
  • Мультиконтейнерные приложения.
  • Обнаружение служб service discovery.
  • Масштабирование сервиса.
  • Run-once задания.
  • Интеграция с Maven.
  • Скользящее обновление.
  • Создание кластера БД Couchbase.

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

Арун Гупта главный технолог open-source продуктов Amazon Web Services, который уже более 10 лет развивает сообщества разработчиков Sun, Oracle, Red Hat и Couchbase. Имеет большой опыт работы в ведущих кросс-функциональных командах, занимающихся разработкой и реализацией стратегии маркетинговых кампаний и программ. Руководил группами инженеров Sun, является одним из основателей команды Java EE и создателем американского отделения Devoxx4Kids. Арун Гупта является автором более 2 тысяч постов в IT-блогах и выступил с докладами более чем в 40 странах.

Конференция DEVOXX UK. Выбираем фреймворк: Docker Swarm, Kubernetes или Mesos. Часть 1

Концепт масштабирования Scale означает возможность управлять количеством реплик, увеличивая или уменьшая число экземпляров приложения.



Для примера: если хотите масштабировать систему до 6 реплик, используйте команду docker service scale web=6.

Наряду с концептом Replicated Service в Docker существует концепт общих сервисов Global Service. Скажем, я хочу запустить экземпляр одного и того же контейнера на каждом узле кластера, в данном случае это контейнер приложения веб-мониторинга Prometheus. Это приложение используется, когда требуется собрать метрики о работе хостов. В этом случае вы используете подкоманду - mode=global - name=prom prom/Prometheus.



В результате приложение Prometheus будет запущено на всех узлах кластера без исключения, и если в кластер будут добавлены новые ноды, то оно автоматически запустится в контейнере и в этих нодах. Надеюсь, вы поняли разницу между Replicated Service и Global Service. Обычно Replicated Service это то, с чего вы начинаете.



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

Оркестровка представляет собой автоматизированное управление связанными сущностями кластерами виртуальных машин или контейнеров.Kubernetes это совокупность сервисов, реализующих контейнерный кластер и его оркестровку. Он не заменяет Docker, но серьёзно расширяет его возможности, упрощая управление развертыванием, сетевой маршрутизацией, расходом ресурсов, балансировкой нагрузки и отказоустойчивостью запускаемых приложений.
По сравнению с Kubernetes, Docker ориентирован именно на работу с контейнерами, создавая их образы с помощью docker-файла. Если сравнить объекты Docker и Kubernetes, можно сказать, что Docker управляет контейнерами, в то время как Kubernetes управляет самим Docker.
Кто из вас имел дело с контейнерами Rocket? А кто-нибудь использует Rocket в продакшене? В зале поднял руку всего один человек, это типичная картина. Это альтернатива Docker, которая до сих пор не прижилась в сообществе разработчиков.

Итак, основной сущностью Kubernetes является Pod. Он представляет собой связанную группу контейнеров, которые используют общее пространство имен, общее хранилище и общий IP-адрес. Все контейнеры в поде общаются друг с другом через локальный хост. Это означает, что вы не сможете разместить приложение и базу данных в одном и том же поде. Они должны размещаться в разных подах, поскольку имеют разные требования масштабирования.



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

Обычно вы обертываете свой контейнер в набор реплик Replica Set, поскольку хотите запускать в поде определенное количество экземпляров. Replica Set приказывает запустить столько реплик, сколько требует сервис масштабирования Docker, и указывает, когда и каким образом это проделать.

Поды похожи на контейнеры в том смысле, что если происходит сбой пода на одном хосте, он перезапускается на другом поде с другим IP-адресом. Как Java-разработчик, вы знаете, что когда создаете java-приложение и оно связывается с базой данных, вы не можете полагаться на динамический IP-адрес. В этом случае Kubernetes использует Service этот компонент публикует приложение как сетевой сервис, создавая статичное постоянное сетевое имя для набора подов, одновременно реализуя балансировку нагрузки между подами. Можно сказать, что это служебное имя базы данных, и java-приложение не полагается на IP-адрес, а взаимодействует только с постоянным именем базы данных.

Это достигается тем, что каждый Pod снабжается определенной меткой Label, которые хранятся в распределенном хранилище etcd, и Service следит за этими метками, обеспечивая связь компонентов. То есть поды и сервисы устойчиво взаимодействуют друг с другом с помощью этих меток.

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



Master-node обеспечивает взаимодействие с пользователем при помощи API-сервера и содержит распределенное хранилище etcd, в котором находится конфигурация кластера, статусы его объектов и метаданные.

Рабочие узлы Worker-node предназначены исключительно для запуска контейнеров, для этого в них установлены два сервиса Kubernetes сетевой маршрутизатор proxy service и агент планировщика kubelet. Во время работы этих узлов Docker выполняет их мониторинг с помощью systemd (CentOS) или monit (Debian) в зависимости от того, какой операционной системой вы пользуетесь.

Рассмотрим архитектуру Kubernetes более широко. У нас имеется Master, в составе которого присутствуют API сервер (поды, сервисы и т.д.), управляемый с помощью CLI kubectl. Kubectl позволяет создавать ресурсы Kubernetes. Он передает API-серверу команды типа создать под, создать сервис, создать набор реплик.

Далее здесь имеется планировщик Scheduler, менеджер контроллеров Controller Manager и хранилище etcd. Менеджер контроллеров, получив указания API-сервера, сопоставляет метки реплик с метками подов, обеспечивая устойчивое взаимодействие компонентов. Планировщик, получив задание создать под, просматривает рабочие ноды и создает его там, где это предусмотрено. Естественно, что он получает эту информацию из etcd.

Далее у нас имеется несколько рабочих нодов, и API-сервер общается с содержащимися в них Kubelet-агентами, сообщая им, как должны создаваться поды. Здесь расположен прокси, который предоставляет вам доступ к приложению, использующему эти поды. Справа на слайде показан мой клиент это запрос интернета, который поступает в балансировщик нагрузки, тот обращается к прокси, который распределяет запрос по подам и направляет ответ обратно.



Вы видите итоговый слайд, который изображает кластер Kubernetes и то, как работают все его компоненты.

Давайте подробнее поговорим о Service Discovery и балансировщике нагрузки Docker. Когда вы запускаете свое Java-приложение, обычно это происходит в нескольких контейнерах на нескольких хостах. Существует компонент Docker Compose, который позволяет с легкостью запускать мультиконтейнерные приложения. Он описывает мультиконтейнерные приложения и запускает их при помощи одного или нескольких yaml-файлов конфигурации.



По умолчанию это файлы docker-compose.yaml и docker-compose.override.yaml, при этом множества файлов указываются с помощью f. В первой файле вы прописываете сервис, образы, реплики, метки и т.д. Второй файл используется для перезаписи конфигурации. После создания docker-compose.yaml он развертывается в мультихостовом кластере, который ранее создал Docker Swarm. Вы можете создать один базовый файл конфигурации docker-compose.yaml, в который будете добавлять файлы специфических конфигураций для разных задач с указанием определенных портов, образов и т.д., позже мы поговорим об этом.

На этом слайде вы видите простой пример файла Service Discovery. В первой строке указывается версия, а строка 2 показывает, что он касается сервисов db и web.



Я добиваюсь того, чтобы после поднятия мой web-сервис мог общаться с db-сервисом. Это простые java-приложения, развертываемые в контейнерах WildFly. В 11 строке я прописываю среду couchbase_URI=db. Это означает, что мой db-сервис использует эту базу данных. В строке 4 указан образ couchbase, а в строках 5-9 и 15-16 соответственно порты, необходимые для обеспечения работы моих сервисов.

Ключом к пониманию процесса обнаружения сервисов служит то, что вы создаете некоторого рода зависимости. Вы указываете, что web-контейнер должен запуститься раньше db-контейнера, но это только на уровне контейнеров. Как реагирует ваше приложение, как оно стартует это совершенно другие вещи. Например, обычно контейнер поднимается за 3-4 секунды, однако запуск контейнера базы данных занимает гораздо больше времени. Так что логика запуска вашего приложения должна быть запечена в вашем java-приложении. То есть приложение должно пинговать базу данных, чтобы убедиться в ее готовности. Поскольку база данных couchbase это REST API, вы должны вызвать этот API и спросить: Эй, ты готов? Если да, то я готов присылать тебе запросы!

Таким образом, зависимости на уровне контейнеров определяются с помощью сервиса docker-compose, но на уровне приложений зависимости и жизнеспособность определяются на основе опросов responsibility. Затем вы берете файл docker-compose.yaml и развертываете в мультихостовом Docker с помощью команды docker stack deploy и подкоманды - compose-file= docker-compose.yaml webapp. Итак, у вас есть большой стек, в котором расположено несколько сервисов, решающих несколько задач. В основном это задачи запуска контейнеров.



Рассмотрим, как работает балансировщик нагрузки Load balancer. В приведенном примере я с помощью команды docker service create создал сервис WildFly контейнер, указав номер порта в виде 8080:8080. Это означает, что порт 8080 на хосте локальной машине будет увязан с портом 8080 внутри контейнера, так что вы сможете получить доступ к приложению через localhost:8080. Это будет порт доступа ко всем рабочим узлам.



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

Итак, запросы клиента поступают балансировщику нагрузки, он перенаправляет их на любой из хостов, и если, используя таблицу IP-адресов, попадает на хост с незапущенным контейнером, то автоматически перенаправляет запрос хосту, на котором запущен контейнер.

Одиночный хоп обходится не дорого, но он полностью бесшовный в отношении масштабирования ваших сервисов в сторону увеличения или уменьшения. Благодаря этому вы можете быть уверены, что ваш запрос попадет именно тому хосту, где запущен контейнер.
Теперь давайте рассмотрим, как работает Service Discovery в Kubernetes. Как я говорил, сервис это абстракция в виде набора подов с одинаковым IP-адресом и номером порта и простым TCP/UDP балансировщиком нагрузки. На следующем слайде показан файл конфигурации Service Discovery.



Создание таких ресурсов, как поды, сервисы, реплики и т.д. происходит на основе файла конфигурации. Вы видите, что он разбит на 3 части с помощью строк 17 и 37, которые состоят только из - -.

Посмотрим сначала на строку 39 в ней значится kind: ReplicaSet, то есть то, что мы создаем. В строках 40-43 расположены метаданные, с 44 строки указывается спецификация для нашего набора реплик. В строке 45 указано, что у меня имеется 1 реплика, ниже указаны ее метки Labels, в данном случае это имя wildfly. Еще ниже, начиная с 50 строки, указывается, в каких контейнерах должна запускаться данная реплика это wildfly-rs-pod, а строки 53-58 содержат спецификацию этого контейнера.

23:05 мин

Продолжение будет совсем скоро


Немного рекламы :)


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Конференция DEVOXX UK. Выбираем фреймворк Docker Swarm, Kubernetes или Mesos. Часть 3

15.06.2020 16:10:07 | Автор: admin
Docker Swarm, Kubernetes и Mesos являются наиболее популярными фреймворками для оркестровки контейнеров. В своем выступлении Арун Гупта сравнивает следующие аспекты работы Docker, Swarm, и Kubernetes:

  • Локальный девелопмент.
  • Функции развертывания.
  • Мультиконтейнерные приложения.
  • Обнаружение служб service discovery.
  • Масштабирование сервиса.
  • Run-once задания.
  • Интеграция с Maven.
  • Скользящее обновление.
  • Создание кластера БД Couchbase.

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

Арун Гупта главный технолог open-source продуктов Amazon Web Services, который уже более 10 лет развивает сообщества разработчиков Sun, Oracle, Red Hat и Couchbase. Имеет большой опыт работы в ведущих кросс-функциональных командах, занимающихся разработкой и реализацией стратегии маркетинговых кампаний и программ. Руководил группами инженеров Sun, является одним из основателей команды Java EE и создателем американского отделения Devoxx4Kids. Арун Гупта является автором более 2 тысяч постов в IT-блогах и выступил с докладами более чем в 40 странах.

Конференция DEVOXX UK. Выбираем фреймворк: Docker Swarm, Kubernetes или Mesos. Часть 1
Конференция DEVOXX UK. Выбираем фреймворк: Docker Swarm, Kubernetes или Mesos. Часть 2

В строке 55 содержится COUCHBASE_URI, указывающий к на сервис этой базы данных, который тоже создан с помощью файла конфигурации Kubernetes. Если посмотреть на строку 2, можно увидеть kind: Service это сервис, который я создаю под именем couchbase-service, и это же имя указанно в строке 4. Ниже приводятся несколько портов.



Ключевыми строками являются 6 и 7. В service я говорю: Эй, вот эти метки, которые я ищу!, и эти labels не что иное, как имена пар переменных, а строка 7 указывает на мое приложение couchbase-rs-pod. Далее перечислены порты, дающие доступ к этим самым labels.

В строке 19 я создаю новый тип ReplicaSet, в строке 31 содержится имя образа, а строки 24-27 указывают на метаданные, ассоциированные с моим подом. Это именно то, что ищет service и с чем должно быть установлено соединение. В конце файла расположен некий вид связи строк 55-56 и 4, говорящий: используй этот service!.

Итак, я запускаю свой service при наличии набора реплик, и поскольку каждый набор реплик имеет свой порт с соответствующей меткой, он включается в состав service. С точки зрения разработчика, вы просто обращаетесь к сервису, который затем задействует нужный вам набор реплик.

В итоге у меня имеется под WildFly, который общается с бэкендом базы данных через Couchbase Service. Я могу использовать фронтенд с несколькими подами WildFly, который также через couchbase service связывается с бэкендом couchbase.



Позже мы рассмотрим, как service, расположенный вне кластера, через свой IP-адрес общается с элементами, которые расположены внутри кластера и имеют внутренний IP-адрес.

Итак, stateless-контейнеры это хорошо, но насколько хороша идея использовать stateful-контейнеры? Давайте рассмотрим настройки системы для stateful, или постоянных контейнеров. В Docker существует 4 различных подхода к расположению хранилища данных, на которые следует обратить внимание. Первый это Implicit Per-Container, означающий, что при использовании satateful-контейнеров couchbase, MySQL или MyDB, все они запускаются с дефолтным Sandbox. То есть все, что хранится в базе данных, хранится в самом контейнере. Если контейнер пропадает, данные пропадают вместе с ним.

Второй это Explicit Per-Container, когда вы создаете конкретное хранилище командой docker volume create и сохраняете в нем данные. Третий подход Per-Host связан с маппингом хранилищ, когда все, что хранится в контейнере, одновременно дублируется на хосте. Если контейнер даст сбой, данные останутся на хосте. Последнее это использование нескольких хостов Multi-Host, что целесообразно на стадии продакшена различных решений. Предположим, ваши контейнеры с вашими приложениями запущены на хосте, но при этом вы хотите хранить свои данные где-то в интернете, причем для этого используется автоматический маппинг для распределенных систем.



Каждый из этих методов использует конкретное местоположение хранилища. Implicit и Explicit Per-Container хранят данные на хосте по адресу /var/lib/docker/volumes. При использовании метода Per-Host хранилище монтируется внутри контейнера, а сам контейнер монтируется на хосте. Для мультихостов могут использоваться решения типа Ceph, ClusterFS, NFS и т.д.

При сбое постоянного контейнера директория хранилища становится недоступной в двух первых случаях, а в двух последних доступ сохраняется. Однако в первом случае вы можете добраться к хранилищу через хост Docker, запущенный на виртуальной машине. Во втором случае данные тоже не пропадут, потому что вы создали Explicit-хранилище.

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

Это следует учитывать при создании stateful-контейнеров. Еще один полезный инструмент Docker это плагин Volume, работающий по принципу батареи присутствуют, но подлежат замене. При запуске контейнера Docker он говорит: Эй, запустив контейнер с базой данных, ты можешь хранить свои данные в этом контейнере! Эта функция по умолчанию, но вы можете ее изменить. Этот плагин позволяет использовать вместо контейнерной БД сетевой диск или что-то подобное. Он включает в себя драйвер по умолчанию для host-based хранилищ и позволяет интеграцию контейнеров с внешними системами хранения данных, такими как Amazon EBS, Azure Storage и постоянными дисками GCE Persistent.

На следующем слайде показана архитектура плагина Docker Volume.



Синим цветом обозначен клиент Docker, связанный с синим Docker-хостом, на котором имеется Local storage engine, предоставляющий вам контейнеры для хранения данных. Зеленым цветом обозначены клиент Plugin Client и Plugin Daemon, которые также подсоединены к хосту. Они предоставляют возможность хранить данные в сетевых хранилищах нужного вам вида Storage Backend.

Плагин Docker Volume может использоваться с хранилищем Portworx. Модуль PX-Dev собственно является запускаемым вами контейнером, который подключается к Docker-хосту и позволяет легко сохранять данные на Amazon EBS.



Клиент Portworx позволяет вам отслеживать состояние контейнеров с различными хранилищами, которые подсоединены к вашему хосту. Если вы посетите мой блог, то сможете прочесть, как наиболее эффективно использовать Portworx с Docker.

Концепция хранилищ в Kubernetes похожа на Docker и представлена директориями, которые доступны вашему контейнеру в поде. Они не зависимы от времени жизни любого контейнера. Наиболее распространенными доступными типами хранилищ являются hostPath, nfs, awsElasticBlockStore и gsePersistentDisk. Рассмотрим, как работают эти хранилища в Kubernetes. Обычно процесс их подключения состоит из 3 шагов.

Первый заключается в том, что кто-то на стороне сети, обычно это администратор, предоставляет вам постоянное хранилище. Для этого имеется соответствующий файл конфигурации PersistentVolume. Далее разработчик приложения пишет файл конфигурации под названием PersistentVolumeClaim, или запрос на хранилище PVC, в котором говорится: у меня подготовлено распределенное хранилище объемом 50Гб, но чтобы другие люди тоже могли использовать его емкость, я сообщаю в этом PVC, что сейчас мне нужно всего 10 Гб. Наконец, третий шаг состоит в том, что ваш запрос монтируется как хранилище, и приложение, в котором имеется под, или набор реплик, или что-то подобное, начинает им пользоваться. Важно помнить, что этот процесс состоит из 3-х упомянутых этапов и позволяет масштабирование.



На следующем слайде показан постоянный контейнер Kubernetes Persistence Container архитектуры AWS.



Внутри коричневого прямоугольника, который изображает кластер Kubernetes, расположен один мастер-нод и два рабочих нода, обозначенные желтым цветом. В одном из worker node находится оранжевый под, хранилище, контроллер реплик и зеленый контейнер Docker Couchbase. Внутри кластера над нодами прямоугольником лилового цвета обозначен доступный извне Service. Эта архитектура рекомендуется для сохранения данных на самом устройстве. При необходимости я могу хранить свои данные в EBS за пределами кластера, как это показано на следующем слайде. Это типичная модель для масштабирования, однако при ее применении нужно учитывать финансовый аспект хранить данные где-то в сети может быть дороже, чем на хосте. При выборе решений контейнеризации это один из весомых аргументов.



Так же, как в случае с Docker, вы можете использовать постоянные контейнеры Kubernetes вместе с Portworx.



Это то, что в нынешней терминологии Kubernetes 1.6 называется StatefulSet способ работы со Stateful-приложениями, которым обрабатываются события об остановке работы Pod и осуществления Graceful Shutdown. В нашем случае такими приложениями являются базы данных. В моем блоге вы можете прочесть, как создавать StatefulSet в Kubernetes при помощи Portworx.
Давайте поговорим про аспект разработки. Как я сказал, Docker имеет 2 версии СЕ и ЕЕ, в первом случае речь идет о стабильной версии Community Edition, которая обновляется раз в 3 месяца в отличие от ежемесячно обновляемой версии ЕЕ. Вы можете скачать Docker для Mac, Linux или Windows. После установки Docker будет автоматически обновляться, и начать работать с ним очень легко.



В Kubernetes я предпочитаю версию Minikube это хороший способ начать работу с этой платформой путем создания кластера на одиночном узле. Для создания кластеров из нескольких нодов выбор версий шире: это kops, kube-aws (CoreOS+AWS), kube-up (устарела). Если вы собираетесь использовать Kubernetes на основе AWS, рекомендую присоединится к группе AWS SIG, которая встречается в сети каждую пятницу и публикует различные интересные материалы по работе с Kubernetes AWS.

Рассмотрим, как на этих платформах выполняется скользящее обновление Rolling Update. Если имеется кластер из нескольких нодов, то в нем используется конкретная версия образа, например, WildFly:1. Скользящее обновление означает, что версия образа последовательно заменяется новой на каждом ноде, один за другим.



Для этого используется команда docker service update (имя сервиса), в которой я указываю новую версию образа WildFly:2 и метод обновления update-parallelism 2. Цифра 2 означает, что система будет обновлять по 2 образа приложения одновременно, затем последует 10-ти секундная задержка update delay 10s, после чего будут обновлены 2 следующих образа еще на 2-х нодах, и т.д. Этот простой механизм скользящего обновления предоставляется вам как составная часть Docker.

В Kubernetes скользящее обновление происходит таким образом. Контроллер репликации rc создает набор реплик одной версии, и каждый под в этом webapp-rc снабжен меткой label, находящейся в etcd. Когда мне нужен какой-то под, я через Application Service обращаюсь к хранилищу etcd, которое по указанной метке предоставляет мне этот под.



В данном случае у нас в Replication controller имеется 3 пода, в которых запущено приложение WildFly версии 1. При обновлении в фоновом режиме создается еще один контроллер репликации с тем же именем и индексом в конце - xxxxx, где х случайные числа, и с теми же метками labels. Теперь Application Service располагает тремя подами с приложением старой версии и тремя подами с новой версией в новом Replication controller. После этого старые поды удаляются, контроллер репликации с новыми подами переименовывается и включается в работу.



Перейдем к рассмотрению мониторинга. В Docker имеется множество встроенных команд для мониторинга. Например, интерфейс командной строки docker container stats позволяет каждую секунду выводить в консоль данные о состоянии контейнеров использование процессора, диска, загрузку сети. Инструмент Docker Remote API предоставляет данные о том, как клиент общается с сервером. Он использует простые команды, но в его основе лежит Docker REST API. В данном случае слова REST, Flash, Remote обозначают одно и то же. Когда вы общаетесь с хостом, это REST API. Docker Remote API позволяет получить больше сведений о запущенных контейнерах. В моем блоге изложены детали использования этого мониторинга с Windows Server.

Мониторинг системных событий docker system events при запуске мультихостового кластера дает возможность получить данные о падении хоста или падении контейнера на конкретном хосте, масштабировании сервисов и тому подобного. Начиная с версии Docker 1.20, в него включен Prometheus, который осуществляет встраивание endpoints в существующие приложения. Это позволяет получать метрики через HTTP и отображать их на панелях мониторинга.

Еще одна функция мониторинга это cAdvisor (сокращение от container Advisor). Он анализирует и предоставляет данные об использовании ресурсов и производительности из запущенных контейнеров, предоставляя метрики Prometheus прямо из коробки. Особенность этого инструмента в том, что он предоставляет данные только за последние 60 секунд. Поэтому вам нужно предусмотреть возможность собирать эти данные и помещать в базу данных, чтобы иметь возможность мониторинга длительного по времени процесса. Его также можно использовать для отображения метрик на панели мониторинга в графическом виде с помощью Grafana или Kibana. В моем блоге есть подробное описание того, как использовать cAdvisor для мониторинга контейнеров с помощью панели Kibana.

На следующем слайде показано, как выглядит результат работы Prometheus endpoint и доступные для отображения метрики.



Слева внизу вы видите метрики HTTP-запросов, ответов и т.д., справа их графическое отображение.

Kubernetes также содержит встроенные инструменты мониторинга. На этом слайде показан типовой кластер, содержащий один мастер и три рабочих узла.



В каждом из рабочих нодов расположен автоматически запускаемый cAdvisor. Кроме этого, здесь имеется Heapster система мониторинга производительности и сбора метрик, совместимая с Kubernetes версии 1.0.6 и выше. Heapster позволяет собирать не только показатели производительности рабочих нагрузок, модулей и контейнеров, но и события и другие сигналы, генерируемые целым кластером. Для сбора данных он общается с Kubelet каждого пода, автоматически сохраняет информацию в базе данных InfluxDB и выводит в виде метрик на панель мониторинга Grafana. Однако учтите если вы используете miniKube, эта функция по умолчанию недоступна, поэтому для мониторинга придется использовать аддоны. Так что все зависит от того, где вы запускаете контейнеры и какими инструментами мониторинга можете воспользоваться по умолчанию, а какие требуется установить в виде отдельных дополнений.

На следующем слайде изображены панели мониторинга Grafana, которые показывают рабочее состояние моих контейнеров. Здесь достаточно много интересных данных. Конечно, существует множество коммерческих инструментов мониторинга процессов Docker и Kubernetes, например SysDig, DataDog, NewRelic. Некоторые из них имеют 30-ти бесплатный пробный период, так что можно попробовать и подобрать себе наиболее подходящий. Лично я предпочитаю использовать SysDig и NewRelic, которые отлично интегрируются в Kubernetes. Существуют инструменты, которые одинаково хорошо интегрируются в обе платформы и Docker, и Kubernetes.


Немного рекламы :)


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Борьба за 5G передел зон влияния, или игра в наперстки?

19.06.2020 00:04:04 | Автор: admin


Быстрее, выше, сильнее Олимпийский девиз, который является весьма актуальным для создаваемой сегодня ИТ-инфраструктуры. Каждый новый вводимый стандарт радиосвязи все более и более увеличивает объем передаваемой информации, уменьшает латентность сети, а также внедряет не мало полезных новшеств, которые далеко не всегда понятны конечному потребителю услуги. На сегодняшний день, как показывает практика, скачек качественных параметров сетей сотовой связи, от старого поколения к новому, можно описать геометрической прогрессией. Соответственно у нас уже сформировано ожидание, что каждый новый стандарт должен стать в разы более функциональным нежели уже существующий. Ожидание вполне оправдано. На нашей с вами памяти внедрение технологий 2-3-4G, собственно, и были такими прорывами, но что на счет 5G?

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

Экспонента


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

Неописуемое преимущество мобильности, которую нам подарили сотовые телефоны в 90-х, смогла затмить разве-что возможность использования своего мобильного гаджета в качестве полноценного интернет модема в сетях 2G. Получив возможность доступа к электронной почте, разного рода информационным порталам, и при этом не привязывая себя к проводной инфраструктуре, на горизонте появилась новая цель преодолеть верхний барьер скорости, а также радикально снизить пинг, в сетях 2G он довольно печальный. Полноценное внедрение стандарта связи 3G, может быть и не было столь волнующим и будоражащим сознание как это было с 2G, однако, бесспорно стало новой вехой для всех нас. Сравнивая 3G с его предшественником можно отметить, что фактическая скорость, как на закачку так и на отдачу, возросла в десятки раз! Кроме феноменального прироста по скорости мы также получили снижение уровня задержек в сети до комфортных 50 мс, что стало на порядок лучше нежели у 2G с его 200+ мс. С приходом третьего поколения сотовой связи, наконец, мобильный интернет стал действительно конкурентной альтернативой его проводному собрату.

Что касается 4G, он удивил еще меньше чем в свое время его предшественник. Да, конечно, интернет с приходом нового стандарта привычно стал еще более шустрый, сети стали еще более емкие. В то же время с точки зрения коммерческой успешности 4G для операторов связи оказался весьма сомнительным приобретением, особенно слабую окупаемость услуги ощутили на себе операторы предоставляющие ее в развивающихся странах. Заоблачные скорости 4G, в теории до 1Гбит/с, у массового потребителя и сейчас вызывают лишь улыбку. Куда более востребованным параметром, для нормального пользования стандартом, является присутствие достаточного количества базовых станций 4G. За последние 5 лет развития зона покрытия 4G в благополучных ФРГ, Франции, Британии охватили около 99% населения, но в масштабах всей Земли это скорее исключение нежели правило. Если взять даже постсоветское пространство то можно увидеть, что 4G все еще пребывает на стадии инвестиций и внедрения. Что же на этом фоне ожидает 5G?


Карта покрытия сетью 4G наиболее крупных операторов сотовой связи ФРГ Украина

Частотный диапазон


По сути тот гигантский скачок, который произошел от сетей 1G до 4G, был произведен в границах единого технологического процесса. Каждая последующая G является, не много не мало, модернизированным ее предшественником. Это, в общем не удивительное понимание приводит нас к пониманию сложившейся сейчас ситуации мы максимально приблизились к границам используемой нами технологии лежащей в основе современных сетей сотовой связи. Увеличение амплитуды передающего канала, новые методы модуляции сигнала давали нам возможность наращивать объем передаваемой информации за единицу времени, но в дальнейшем существенный прирост в скорости сети возможен будет лишь через существенное повышения рабочей частоты, а это весьма чревато последствиями.


Оценка количества базовых станций для покрытия 100% территории Украины в зависимости от их рабочих частот

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

Альтернативой высоким частотам может стать внедрение 5G на частотах низких, до 1 ГГц, это позволит сделать полноценное покрытие обширных территорий, однако при таком сценарии рядовой пользователь изменений в работе своего гаджета, от привычного уже эму 4G, фактически не заметит. Как следствие, 5G рискует стать головной болью маркетологов, обладая некоторым заделом на далекое будущие, неся в себе более глубокие бенефиты, скажем, для мира LoT, массовый же пользователь за него переплачивать явно не будет.



А что если?


Если на низких частотах 5G конкурент для 4G, то логично допустить, что новый стандарт будет запущен на частотах 5 ГГц и выше. Ведь согласно новому стандарту он может быть запущен на частотах вплоть до 300 ГГц. Но тут мы натыкаемся на новое препятствие, использование сотовым устройством миллиметрового диапазона порождает конфликт с конкурентом в лице технологии WiFi.

WiFi давний неприятель для операторов мобильной связи. Заняв золотую середину между ценой проводного мегабайта и уровнем мобильности он крепко обосновался в наших домах, офисах, транспорте и даже парках. Имея схожие c 5G принципы беспроводной передачи данных технология WiFi шла своим путем становления и надежно занимала свою уникальную ниши, до самого последнего времени.



Честно говоря ситуация с ИТ-коммуникациями давно уже стала весьма абсурдна, и вот в чем дело. Непонятно кто первый полез в чей огород интернет провайдеры со своей IP-телефонией к операторам сотовой связи, или операторы со своими 2-3-4-5G стали отбирать интернет трафик у мелких провайдеров, однако сейчас конфликт интересов на лицо. Операторы мобильной связи фактически стали интернет провайдерами, интернет провайдеры остались интернет провайдерами, но при этом остались адептами несколько другой архитектуры построения сети. По сути мы стали свидетелями конвергентной эволюции в ИТ. Если рассматривать внедряемый стандарт 5G не с точки зрения смены поколения 4G, который он со временем должен полностью заместить, как это фактически происходило с 2-3G ранее, а назвать его, скажем, убийцей WiFi? В таком случае многие неувязки и странности связанные с 5G могут оказаться весьма понятными и занять свое место в логической цепи.

Итоги


Интернет каналы по которым мы можем коммуницировать со всем миром идентичны и для крупного мобильного оператора и для мелкого провайдера домашнего проводного интернета. Бизнес для обоих начинается на уровне клиент провайдер. То каким способом мы с вами попадем во всемирную паутину и есть многомиллиардный бизнес заваренный на разных технологиях, оборудовании, торговых марках. Ситуация, когда мы используем два разных подхода к организации доступа к интернету ранее имела смысл, и видимо завтра это не закончится, однако мир стремится к упрощению. Отказ от использования услуг классических провайдеров станет следствием создания корпорациями универсальных способов доступа к интернету посредством универсальных сотовых сетей. Универсальные модули связи, универсальные гаджеты облегченные от невостребованных блоков WiFi, Bluetooth, LAN. Централизованное наведения порядка с организацией устойчивого покрытия, ликвидации (существенное уменьшение) радиочастотной загрязненности офисов, особенно многоквартирных домов, от этого однозначно выиграет конечный потребитель. Неужели это так уж плохо? Может действительно пора сделать этот качественный скачек?

Кто-то может сказать, что все это бред, мол WiFi идет своим путем развития и обладает весьма удобным набором особенностей, что не даст ему просто так погибнуть. Может и так, на новых ноутбуках и сейчас можно встретить и Bluetooth, и выход под разъем RJ-45, однако все реже и реже. То что сделал WiFi с ними, в один прекрасный момент c WiFi может сделать 5G.



При таком развитии событий остается опасаться лишь одного, если WiFi станет анахронизмом и уделом гиков, не попадем ли мы в мохнатые лапы нескольких операторов-монополистов? Неужели мы снова вспомним о забытых как страшный сон: посекундной тарификацией IP-телефонии, конским тарифам за мегабайт, роуминге и других прелестях? Все эти вопросы, очевидно, дня завтрашнего, однако не стоит забывать сегодня это вчерашнее завтра, и мы с вами являемся эму свидетелями.

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Перевод Конференция QCon. Овладение хаосом руководство Netflix для микросервисов. Часть 1

21.06.2020 00:16:48 | Автор: admin
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Около 15 лет назад моя мачеха, назовем ее Фрэнсис, стала чувствовать боль и слабость во всем теле, ей стало трудно стоять, и когда врачи в больнице немного привели ее в себя, у нее обнаружился паралич рук и ног. Это было ужасное испытание для нее и для нас, как оказалось, диагнозом стал синдром Гийона-Барре. Мне просто любопытно, кто-нибудь из вас слышал о такой болезни? О, довольно много людей! Надеюсь, вы получили эту информацию не из первых рук. Это аутоиммунное заболевание, острый полирадикулоневрит, при котором иммунная система человека поражает собственные периферические нервы.



Обычно эту болезнь провоцирует какой-то внешний фактор, но интересно в ней то, что антитела атакуют непосредственно миелиновую оболочку аксона так, что повреждают ее по всей длине нерва, и его сигналы становятся очень рассеянными. Поэтому можно логично объяснить все симптомы боли, слабости и паралич, понимая, что происходит с нервной системой. Хорошие новости состоят в том, что это заболевание можно вылечить либо через плазмаферез, когда кровь фильтруется вне вашего тела, либо с помощью антительной терапии.

Лечение Френсис прошло успешно, но болезнь заставила ее более дисциплинированно относиться к своему здоровью. Она начала правильно питаться, заниматься спортивными упражнениями, освоила цигун и тайцзи и делала все, чтобы исключить риск повторения подобных болезней.
Этот случай подчеркивает, насколько удивительно человеческое тело. Простой акт дыхания или взаимодействие с окружающим миром представляют собой чудесные вещи и являются настоящим подвигом, ведь в окружающем нас мире существует множество вредоносных сил, аллергенов и бактериальных инфекций, способных вызвать огромные проблемы.

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

Я начну со вступления, в котором вам представлюсь, затем займу немного времени объяснением базовых основ микросервисов. Большую часть доклада я посвящу проблемам и их решениям, которые предлагает Netflix. В завершении я расскажу о зависимостях организации процессов и соответствующей им архитектуры.

Я Джош Эванс, который начал работу в Netflix в 1999 году, перед этим сделав карьеру в схожей области. Я пришел в проект за месяц до запуска DVD-сервиса, работал инженером, менеджером и был участником интеграции коммерческого продукта и стриминга в существующий DVD-бизнес. В 2009 я попал прямо в сердце потокового мультимедиа, возглавив команду Playback Service службу, которая занимается доставкой DRM, манифестов и записью телеметрии, возвращающейся из устройств пользователей. Я также управлял этой командой во время международного внедрения Netflix, когда наш сервис заработал практически на всех устройствах, воспроизводящих потоковое видео, и участвовал в переносе проекта с дата-центров в облачный сервис. Можно сказать, что последние 3 года были самыми захватывающими. Я возглавлял команду инженеров Operations Engineering, которая фокусируется на высокопрофессиональных операциях контроля скорости, мониторинге и предупреждении сбоев, доставке потокового мультимедиа и широком спектре функций, поиогающих инженерам Netflix успешно эксплуатировать свои собственные облачные сервисы.

Примерно месяц назад я ушел из Netflix и сегодня наверстываю упущенное с книгой Арианны Хаффингтон The Sleep Revolution: Transforming Your Life, One Night at a Time. Впервые за довольно долгое время я взял отпуск и провожу его с семьей, пытаясь выяснить, как создать баланс между работой и личной жизнью.

Как известно, Netflix является лидером в области абонентского интернет-телевидения, предоставляющим пользователям голливудскую кинопродукцию, инди, локальные передачи, растущий пласт оригинального контента. У нас 86 млн. пользователей в 190 странах, стриминг на 10 языках и поддержка более 1000 типов устройств. Все это работает на основе микросервисов AWS.



Давайте поговорим о микросервисах с абстрактной точки зрения. Начнем с того, какими они не должны быть. Дата-центр Netflix DVD образца 2000 года имел достаточно простую инфраструктуру: аппаратный балансировщик нагрузки, кстати, достаточно дорогой, хост Linux стандартной конфигурации с Apache Reverse Proxy и Tomcat, и всего одно приложение, названное нами Javaweb.



Хост напрямую соединялся через JDBC с базой данных Oracle, которая, в свою очередь, соединялась с другой, биллинговой базой данных Oracle через DB link. Первой проблемой данной архитектуры была монолитность кодовой базы Javaweb, то есть все вкладывалось в одну единственную программную базу, обновляемую еженедельно или раз в 2 недели. Любое внеочередное изменение становилось проблемой, которую было достаточно трудно диагностировать. Например, мы потратили почти неделю, разбираясь с медленной памятью. Мы вытягивали куски кода, запускали его, смотрели, что при этом происходит и так далее, поэтому внесение любых изменений занимало много времени. База данных представляла собой еще более строгий монолит это был один сегмент оборудования, работающй с одной большой базой данных Oracle, которую мы называли Базой данных магазина. Если она выходила из строя, то из строя выходило абсолютно все. Каждый год с началом периода отпусков мы наращивали аппаратные мощности, чтобы вертикально масштабировать наше приложение.

Наиболее болезненным был недостаток оперативности мы не могли вносить изменения достаточно быстро, поскольку все компоненты архитектуры были жестко связаны друг с другом. У нас были прямые обращения к базе данных, множество приложений, обращавшихся к табличным схемам, поэтому даже добавление столбца в таблицу становилось большой проблемой для кросс-функционального проекта. Это хороший пример того, как сегодня не нужно создавать сервисы, хотя подобная картина была типичной для конца 90-х начала 2000 годов.

Так что же такое микросервис? Кто-нибудь хочет дать ему определение? Мне нравится, что вы сказали: привязка к контексту и владение данными. Я приведу вам определение Мартина Фаулера: Архитектурный стиль микросервисов представляет собой подход к разработке одного приложения как совокупности мелких сервисов, каждый из которых имеет собственный рабочий процесс и осуществляет коммуникацию с помощью легких механизмов, преимущественно в виде API на основе HTTP-ресурсов.

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

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

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

Давайте рассмотрим архитектуру Netflix и то, как она мапируется.

Слева вы видите клиентский сервис конечный уровень ELB-прокси под названием Zuul, который осуществляет динамическую маршрутизацию. Здесь же расположен NCCP (Netflix Content Control Plane), который поддерживает предыдущие поколения наших устройств и обеспечивает воспроизводящую способность контента. API-шлюз, являющийся ядром нашей современной архитектуры, обращается ко всем другим сервисам для выполнения запросов клиентов.



Справа расположена подсистема среднего уровня Middle Tier и платформа сервиса. Это среда, состоящая из множества компонентов, таких как A/B тестирование, сообщающее результаты пользовательских проверок. Абонентский сервис Subscriber предоставляет развернутую информацию о клиентах, система рекомендаций Recommendations обеспечивает информацию, необходимую для создания списка фильмов, которые будут представлены каждому клиенту.

К платформенным сервисам относятся маршрутизация микросервисов, позволяющая службам находить друг друга, динамическая конфигурация, операции шифрования. Здесь также имеется уровень хранения Persistence, где расположены кеш и база данных.

Эти виды объектов формируют экосистему Netflix. Хочу подчеркнуть, что так как микросервисы являются абстракцией, мы склонны думать о них очень упрощенно. На этом слайде показан мой любимый горизонтально масштабируемый микросервис. Прекрасно, что микросервисы кажутся простыми, однако в реальности почти никогда таковыми не являются. В какой-то момент вам потребуются данные, которые нужно вытянуть из базы данных. Это может быть абонентская информация Subscriber или рекомендации Recommendations. Обычно эти данные находятся на уровне хранения Persistence. На схеме показан обычный подход к получению пользовательских данных, который использует не только сервис Netflix.

Service Client начинает предоставлять клиентские библиотеки на основе Java, которые обеспечивают доступ к базовым данным. Наступает момент, когда вам потребуется масштабировать сервис, привлекая к этому EVCashe Client, потому что сервис с разросшейся базой данных недостаточно хорошо справляется с клиентской нагрузкой. EVCache это распределенное решение для кэширования в памяти, основанное на memcached & spymemcached, интегрированное с инфраструктурой Netflix OSS и AWS EC2. После подключения клиента EVCashe вы должны будете заняться оркестровкой, чтобы, если это хранилище выйдет из строя, вы смогли бы обратиться к Service Client, который вызовет базу данных и вернет ответ обратно. При этом вы должны убедиться в том, что произошло наполнение EVCashe так, что при следующем обращении к нему спустя несколько миллисекунд все будет в порядке.



Эта клиентская библиотека встраивается в клиентское приложение, которое использует микросервис, представляющий собой цельный набор технологий и комплекс конфигураций. Это не простая stateless-структура, которой легко управлять, а сложная комплексная структура.
Итак, рассмотрев основы архитектуры микросервисов, перейдем к проблемам, с которыми мы сталкивались на протяжении последних 7 лет, и их решениям. Я люблю нездоровую пищу и мне нравится эта картинка, потому что я думаю, что во многих случаях проблемы и их решения должны быть связаны с нашими привычками, в нашем случае с тем, как мы подходим к микросервисам. Поэтому во многих случаях нашей целью является организовать здоровое питание и потреблять как можно больше овощей.

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



Первый случай это внутренние запросы на обслуживание Intra-service requests, например, запросы микросервиса А микросервису В. По аналогии с нервными клетками и нервной проводимостью все идет прекрасно, пока нам не приходится перепрыгивать через бездну в случае, когда один сервис вызывает другой, существует огромный риск сбоя.



Этот риск вызван задержками сети, перегрузкой, отказами аппаратной части. Вызываемый сервис может иметь логические ошибки или неполадки масштабирования. Он может работать очень медленно и выдавать при вызове ошибку таймаута. Самый ужасный сценарий, который реализовывался чаще, чем хотелось, это когда сбой всего одного сервиса при развертывании приводил к отказу всей системы, из-за чего клиент утрачивал с ней всякую связь. И упаси вас боже развернуть эти ошибочные изменения на несколько регионов при использовании мультирегиональной стратегии, потому что вам просто некуда будет отступить, чтобы восстановить и отремонтировать систему.

Продолжение будет совсем скоро


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Перевод Конференция QCon. Овладение хаосом руководство Netflix для микросервисов. Часть 2

22.06.2020 00:17:16 | Автор: admin
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 1

Для защиты приложений от неполадок такого рода мы разработали HYSTRIX имплементацию корпоративного шаблона Circuit Breaker, предохранитель, который контролирует задержки и ошибки при сетевых вызовах.



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

Таким образом, преимущество HYSTRIX это изолированные пулы потоков и понятие цепи. Если несколько вызовов сервиса В безуспешны, сервис А перестанет их совершать и будет ждать восстановления. В свое время HYSTRIX был инновационным решением, но при его использовании возникал вопрос: у меня есть вся история настроек, я уверен, что все сделано правильно, но как узнать, что он действительно работает?

Лучший способ узнать это (вспомним наши биологические аналогии) вакцинация, когда вы берете мертвый вирус и вводите его в организм, чтобы стимулировать борьбу антител с живым вирусом. В продакшене роль прививки играет фреймворк Fault Injection Testing (FIT) тестирование, которое позволяет находить проблемы микросервисов путем создания искусственных сбоев. С его помощью выполняются синтетические транзакции на уровне устройств или аккаунтов, либо увеличивается объем живого трафика вплоть до 100%. Таким образом проверяется надежность микросервисов под стрессовой нагрузкой.



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

Это хорошо, если рассматривать соединения точка-точка. Но представьте, что ваша система состоит из сотни микросервисов, и каждый из них зависит от других. Как проверить такую систему, не проводя миллионов тестов, во время которых сервисы вызывают друг друга?
Допустим, у вас имеется 10 сервисов в цельной структуре микросервиса, и каждый из них обладает 99,99% доступностью. Это означает, что на протяжение года каждый сервис может быть не доступным 53 минуты.



Если бы сервисы работали независимо, в этом не было бы ничего критичного, но когда они зависят друг от друга, суммарное время отказа всего микросервиса может достигать 8-9 часов в год, а это уже большая разница.

Из вышесказанного возникает концепция критических микросервисов это минимальный уровень обслуживания, который клиент хотел бы получить в случае сбоев, т. е. базовая возможность просмотра контента, например, из списка только популярных фильмов. Клиенты будут мириться с потерей некоторых дополнительных услуг, таких как персонализация, пока они могут достичь хотя бы этого. Используя данный подход, мы идентифицировали такие сервисы и сгруппировали их, создав FIT рецепт. Фактически это черный список, в который входят все остальные сервисы, не являющиеся критическими.



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

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

Представьте, что у меня есть общая логика и общие шаблоны доступа для вызова моего сервиса и есть 20 или 30 разных зависимостей. Действительно ли я захочу, чтобы каждая отдельная команда разработчиков писала один и тот же или немного отличающийся код снова и снова, или же захочу объединить все в общую бизнес-логику и общие шаблоны доступа? Это было настолько очевидно, что мы внедрили именно такое решение.

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

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



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

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



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

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

На слайде показан сетевой сервис А, который записывает в 3 базы данных копии одинаковых данных. Каждая из баз работает с одной из 3 сетей, обеспечивая доступность. Вопрос в том, что делать, если вы потеряете связь с одной из БД у вас возникнет сбой и сообщение об ошибке, либо вы продолжите работу с двумя остальными БД, пока неполадка не будет устранена.



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



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

Теперь поговорим об инфраструктуре, потому что это отдельная важная тема. Когда-нибудь ваша инфраструктура, будь то AWS, Google или ваша собственная разработка, может отказать, потому что отказать может все что угодно. Вы видите заголовок статьи Forbes о том, что Amazon AWS обвалил Netflix в канун Рождества 2012 года.



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



Мы поместили все свои сервисы на сервер US-East-1, и когда там произошел сбой, нам было некуда отступать. После этого случая мы внедрили мультирегиональную стратегию с тремя регионами AWS так, что если один из них давал сбой, мы могли перевести весь трафик на два других региона.



Ранее в этом году я уже выступал на QСon London с докладом о глобальной архитектуре Netflix, так что вы можете просмотреть это выступление, если хотите вникнуть в тему достаточно глубоко.
Перейдем к масштабированию и рассмотрим три его составляющих: stateless-сервисы, stateful-сервисы и гибридные сервисы. Что же такое stateless-сервис? Кто-нибудь из присутствующих может дать определение? Начну с того, что это не кеш или база данных, где вы храните массивный объем информации. Вместо этого у вас есть часто используемые метаданные, кэшируемые в энергонезависимой памяти.

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

26:30 мин

Продолжение будет совсем скоро


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Перевод Конференция QCon. Овладение хаосом руководство Netflix для микросервисов. Часть 3

24.06.2020 00:13:58 | Автор: admin
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 1
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 2

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



У вас есть минимум и максимум, есть метрики, которыми вы пользуетесь, когда увеличиваете свою группу. Если нужен новый экземпляр, вы просто вытягиваете и раскручиваете любой образ из S3. В этом есть ряд преимуществ. Во-первых, это эффективное использование компьютерных мощностей, поскольку вы изменяете их по требованию. Вышедшие из строя узлы легко замещаются новыми. Но самое важное то, что при всплесках трафика, например, во время DDoS-атак или вследствие ошибок производительности, автомасштабирование позволяет сохранять работоспособность системы в то время как вы разбираетесь с причинами и устраняете неполадки. Я настоятельно рекомендую использовать это масштабирование, потому что оно неоднократно спасало нас от серьезных сбоев.

И конечно же, вы хотите убедиться в его постоянной работе с помощью Chaos. Обезьянка Хаоса Chaos Monkey это наш инструмент, который случайным образом уничтожает экземпляры AWS или процессы на серверах, которые обслуживают сервис Netflix. Этот инструмент подтверждает, что если один из узлов узел умирает, то все остальное продолжает работать без проблем. После внедрения Chaos Monkey мы получили возможность круглосуточно убеждаться в том, что все ноды имеют избыточное дублирование, падение одного узла не приводит ни к каким последствиям, а каждая неполадка документируется для того, чтобы впоследствии для ее устранения можно было применить готовое решение.



Давайте рассмотрим, что же представляют собой Stateful-сервисы. Это базы данных, кэши и пользовательские приложения, использующие внутренние кэши с большим объемом данных. Когда мы внедряли мультирегиональную архитектуру и пытались использовать общие стратегии репликации данных, такие приложения создали большую проблему. Поэтому я настоятельно рекомендую по возможности избегать хранения вашей бизнес-логики и состояний внутри одного приложения. Stateful-сервисы характеризуются тем, что потеря одного узла является значимым для системы событием. Замена этого узла новым может занять несколько часов.

Существует два различных подхода к кэшированию. Как я уже говорил, в наш коллектив влились бывшие сотрудники Yahoo, имевшие большой опыт работы с кэшами ha-proxy. Они использовали шаблон из выделенных серверов для пользователей. То есть пользователь всегда попадал на один и тот же узел, где располагался кеш с единственной копией данных. Проблема заключалась в том, что при поломке этого узла пользователь терял доступ ко всему сервису. На ранней стадии существования сервиса, еще до внедрения HYSTRIX, возникали ситуации, когда выход из строя одного узла обрушивал весь сервис Netflix. Устранение неполадки занимало 3,5 часа, в течение которых мы ждали, пока кеш сам себя наполнит, чтобы можно было выполнить запрос.

На следующем слайде показана схема выделенных сегментов Dedicated Shards, представляющая собой отказ от использования шаблона пользовательского dedicated-сервера.



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

Основной технологией в этом сценарии является совместное использование записи в EVCache. Данные записываются не только на несколько узлов, но и в несколько зон доступности. Чтение из них происходит локально, но опять же приложение может читать из нескольких зон, если это необходимо.



Это очень успешная модель, которую использует практически каждый виртуальный сервис Netflix.
Давайте поговорим о гибридных сервисах, представляющих собой комбинацию stateless и stateful сервисов. В данном случае очень легко использовать EVCache как наиболее подходящую технологию обеспечения отказоустойчивости.



Она позволяет обрабатывать 30 миллионов запросов в секунду, это 2 триллиона запросов в день. В EVCache могут храниться сотни миллиардов объектов и десятки тысяч экземпляров класса memcashed. Огромным преимуществом этой архитектуры является линейная масштабируемость, благодаря чему запросы возвращаются в течение нескольких миллисекунд независимо от нагрузки. Конечно, вам необходимо создать достаточно узлов, но сам процесс масштабирования чрезвычайно прост.



Несколько лет назад мы использовали сценарий, когда наш сервис Subscribers полагался на EVCache в несколько большей степени, чем это было необходимо, то есть имелся антипаттерн, о котором мы уже говорили. К Subscribers обращались практически все остальные сервисы. Я имею ввиду, что все хотели о нем знать, всем нужен был ID клиента, то, как получить доступ к аккаунтам и другая информация. Все оффлайн и онлайн вызовы поступали в один и тот же кластер.

Во многих случаях имели место многократные вызовы одного и того же приложения, получалось, что вы могли вызывать EVCache так часто, как вам хотелось, и на пике активности мы наблюдали от 800 тысяч до миллиона запросов в секунду. Fallback был бы логичным, если думать о нем в сиюминутном аспекте: если кеш дал сбой, дайте мне возможность вызвать сервис. Однако и с Fallback существовала проблема: когда весь уровень EVCache давал сбой, то все запросы поступали к сервису и базе данных и возникал антипаттерн сервис с базой данных не мог справиться с той нагрузкой, которую принимал на себя EVCache. Получалось, что вроде бы правильный подход тоже приводил к неудаче сбой EVCache вызывал отказ всего сервиса Subscribers.



Решение этой проблемы носит комплексный характер:

  • прекратить долбежку одного и того же кластера системы оффлайн-запросами и вызовами в режиме реального времени, разделив рабочую нагрузку на онлайн и оффлайн сегменты;
  • организовать Request-level cashing, то есть всегда привязывать жизненный цикл записи к текущей области запроса, чтобы стало невозможно вызывать один и тот же сервис снова и снова;
  • встраивание в устройства пользователей токенов безопасности Fallback.

Последнее это то, чего у нас пока нет и что будет внедрено в ближайшее время. Если клиент обращается к сервису Subscribers, когда он недоступен, будет осуществлен Fallback к данным, которые хранятся в этом зашифрованном токене. Токен содержит достаточно информации, чтобы идентифицировать пользователя и предоставить ему возможность совершать основные операции для использования нашего сервиса.



Рассмотрим вариации различные варианты архитектуры сервиса. Чем больше таких вариантов, тем больше можно решить проблем, возникающих при увеличении масштаба системы, операционных отклонениях Operational drift, при которых эксплуатационные показатели отличаются от базовых показателей работы сервиса, или при внедрении новых языков или контейнеров.

Operational drift это неизбежное старение различных факторов поддержания сложной системы, которое происходит неумышленно. Отклонения выражаются в периодическом возникновении пороговых нагрузок, таймаутов, задержек, падении производительности при добавлении нового функционала. Однако ручной труд по устранению проблем в данной области не особо эффективен и часто требует повторения одних и тех же манипуляций с небольшими отличиями исходных данных. Можно сказать, что этот процесс основан на голом энтузиазме команды разработчиков.

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

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



В течение нескольких лет мы аккумулировали лучшие практики и сформулировали общие принципы, которые назвали Production Ready, или Готовый продукт. Это чеклист, или программа действий Netflix. Каждый из принципов основан на автоматизации и постоянном улучшении модели взаимодействия с сервисом:

  • Оповещения Alerts
  • Apache & Tomcat
  • Автоматический canary-анализ
  • Автоматическое масштабирование
  • Модель хаоса
  • Согласованные, непротиворечивые наименования
  • ELB config
  • Проверка работоспособности Healthchek
  • Неизменяемые образы машин
  • Squeeze тестирование. Оно состоит в запуске определенных тестов или бенчмарков для того, чтобы увидеть изменения в производительности и вычислить критическую точку приложения. Затем проверяется, было ли это последнее изменение неэффективным, или же оно определяет рекомендуемые параметры автоматического масштабирования перед развертыванием.
  • Red/Black развертывания, заключающиеся в релизе, который сокращает время простоя и риски за счет запуска двух идентичных производственных сред, Red и Black. В любой момент времени только одна из сред является живой, причем она обслуживает весь трафик.
  • Тайм-ауты, повторные попытки, fallback.


Продолжение будет совсем скоро


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Перевод Конференция QCon. Овладение хаосом руководство Netflix для микросервисов. Часть 4

26.06.2020 00:04:47 | Автор: admin
Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 1
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 2
Конференция QCon. Овладение хаосом: руководство Netflix для микросервисов. Часть 3

В отличии от operational drift, внедрение новых языков для интернационализации сервиса и новых технологий, таких как контейнеры, это сознательные решения добавить новую сложность в окружающую среду. Моя группа операционистов стандартизировала асфальтированную дорогу лучших технологий для Netflix, которые запекались в заранее определенных наилучших практиках, основанных на Java и EC2, однако по мере развития бизнеса разработчики стали добавлять новые компоненты, такие как Python, Ruby, Node-JS и Docker.



Я очень горжусь тем, что мы первыми сами выступали за то, чтобы наш продукт отлично работал, не дожидаясь жалоб клиентов. Все начиналось достаточно просто у нас были операционные программы на Python и несколько бэк-офисных приложений на Ruby, но все стало намного интересней, когда наши веб-разработчики заявили, что намерены отказаться от JVM и собираются перевести веб-приложение на программную платформу Node.js. После внедрения Docker вещи стали намного сложнее. Мы руководствовались логикой, и придуманные нами технологии стали реальностью, когда мы внедрили их для клиентов, потому что они имели большой смысл. Расскажу вам, почему это так.

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

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

Логично было взять эти endpoints и вытянуть их из API-сервиса. Для этого мы создали компоненты Node.js, которые запускались как небольшие приложения в контейнерах Docker. Это позволило изолировать любые неполадки и сбои, вызванные этими node-приложениями.

Стоимость этих изменений достаточно велика и складывается из следующих факторов:

  • Инструменты повышения производительности. Управление новыми технологиями требовало новых инструментов, потому что UI-команда, использующая очень удачные скрипты для создания эффективной модели, не должна была тратить много времени на управление инфраструктурой, она должна была заниматься только написанием скриптов и проверкой их работоспособности.
    Инсайт и сортировка возможностей ключевым примером являются новые инструменты, необходимые для выявления информации о факторах производительности. Нужно было знать, на сколько % занят процессор, как используется память, и сбор этой информации требовал разных инструментов.
  • Фрагментация базовых образов простая базовая AMI стала более фрагментированной и специализированной.
  • Управление узлами. Не существует доступной готовой архитектуры или технологий, которые позволяют управлять узлами в облаке, поэтому мы создали Titus платформу управления контейнерами, которая обеспечивает масштабируемое и надежное развертывание контейнеров и облачную интеграцию с Amazon AWS.
  • Дублирование библиотеки или платформы. Предоставление новым технологиям одних и тех же основных функций платформы потребовало ее дублирования в облачные инструменты разработчиков Node.js.
  • Кривая обучения и производственный опыт. Внедрение новых технологий неизбежно создает новые проблемы, которые необходимо преодолеть и извлечь из них уроки.

Таким образом, мы не могли ограничиться одной асфальтированной дорогой и должны были постоянно строить новые пути для продвижения своих технологий. Для снижения стоимости мы ограничивали централизованную поддержку и фокусировались на JVM, новых узлах и Docker. Мы расставляли приоритеты по степени эффективного воздействия, информировали команды о стоимости принятых ими решений и стимулировали их искать возможность многократного использования уже разработанных эффективных решений. Мы использовали этот подход при переводе сервиса на иностранные языки для доставки продукта интернациональным клиентам. Примерам могут служить относительно простые клиентские библиотеки, которые могут генерироваться автоматически, так что достаточно легко создавать Python-версию, Ruby-версию, Java-версию и т.д.

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

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



Как можно достичь высокой скорости внедрения программных инноваций, то есть постоянно вносить новые изменения в систему, не вызывая перерывов в доставке сервиса и не создавая неудобств нашим клиентам? Netflix добились этого благодаря использованию Spinnaker новой глобальной облачной платформы управления и непрерывной доставки (СD).



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



Нам удалось использовать в конвейере доставки две технологии, которые мы высоко ценим: автоматизированный canary-анализ и поэтапное развертывание. Canary-анализ означает, что мы направляем ручеек трафика в новую версию кода, а остальной продакшн-трафик пропускаем через старую версию. Затем мы проверяем, как справляется с задачей новый код лучше или хуже существующего.

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



В конце выступления я коротко расскажу об организации и архитектуре Netflix. В самом начале у нас была схема под названием Electronic Delivery электронная доставка, представлявшая собой первую версию потоковой передачи медиаконтента NRDP 1.x. Здесь можно использовать термин обратный поток, потому что изначально пользователь мог только скачивать контент для последующего воспроизведения на устройстве. Самая первая платформа электронной доставки Netflix образца 2009 года выглядела примерно так.



Пользовательское устройство содержало в себе приложение Netflix, которое состояло из интерфейса UI, модулей безопасности, активации сервиса и воспроизведения, базирующихся на платформе NRDP Netflix Ready Device Platform.

В то время пользовательский интерфейс был очень прост. Он содержал так называемый Queque Reader, и пользователь заходил на сайт, чтобы добавить что-то в Queque, а затем просматривал добавленный контент на своем устройстве. Положительным было то, что клиентская команда и серверная команда принадлежали одной организации Electronic Delivery и имели тесные рабочие взаимоотношения. Полезная нагрузка была создана на основе XML. Параллельно был создан API Netflix для DVD бизнеса, который стимулировал сторонние приложения направлять трафик в наш сервис.

Однако Netflix API был хорошо подготовлен к тому, чтобы помочь нам с инновационным пользовательским интерфейсом, в нем содержались метаданные всего контента, сведения о том, какие фильмы доступны, что создавало возможность генерировать списки просмотра. У него был общий REST API, базирующийся на схеме JSON, HTTP Response Code, такой же, что используется в современной архитектуре, и модель безопасности OAuth то, что требовалось в то время для внешнего приложения. Это позволило перейти от публичной модели доставки потокового контента к приватной.



Проблема перехода заключалась во фрагментации, так как теперь в нашей системе функционировали два сервиса, основанные на совершенно разных принципах работы один на Rest, JSON и OAuth, другой на RPC, XML и механизме безопасности пользователей на основе системы токенов NTBA. Это была первая гибридная архитектура.

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



В связи с этим у меня был разговор с одним из старших инженеров компании, которому я задал вопрос: Что должна представлять собой правильная долгосрочная архитектура?, и он задал встречный вопрос: Вероятно, тебя больше волнуют организационные последствия что произойдет, если мы интегрируем эти вещи, а они сломают то, что мы хорошо научились делать?. Этот подход очень актуален для закона Конвея: Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации. Это очень абстрактное определение, поэтому я предпочитаю более конкретное: Любая часть программного обеспечения отражает организационную структуру, которая его создала. Приведу вам мое любимое высказывание, принадлежащее Эрику Реймонду: Если над компилятором работают четыре команды разработчиков, то в итоге вы получите четырехпроходный компилятор. Что же, Netflix имеет четырехпроходный компилятор, и это то, как мы работаем.

Можно сказать, что в этом случае хвост машет собакой. У нас на первом месте не решение, а организация, именно она является драйвером архитектуры, которую мы имеем. Постепенно от мешанины сервисов мы перешли к архитектуре, которую назвали Blade Runner Бегущий по лезвию, потому что здесь речь идет о граничных сервисах и возможностях NCCP разделяться и интегрироваться напрямую в Zuul-прокси, API-шлюз, причем соответствующие функциональные куски были превращены в новые микросервисы с более продвинутыми функциями безопасности, воспроизведения, сортировки данных и т.д.

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


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Перевод Kонференция NDС London. Предотвращение катастрофы микросервисов. Часть 1

27.06.2020 16:12:41 | Автор: admin
Вы потратили месяцы, переделывая свой монолит в микросервисы, и наконец, все собрались, чтобы щелкнуть выключателем. Вы переходите на первую веб-страницу и ничего не происходит. Перезагружаете ее и снова ничего хорошего, сайт работает так медленно, что не отвечает в течение нескольких минут. Что же случилось?

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



Приветствую всех, я Джимми, и сегодня вы услышите, как можно избежать мегакатастроф при создании микросервисов. Эта история компании, в которой я проработал около полутора лет, чтобы помочь предотвратить столкновение их корабля с айсбергом. Чтобы рассказать эту историю должным образом, придется вернуться в прошлое и поговорить о том, с чего начиналась эта компания и как со временем росла ее ИТ-инфраструктура. Чтобы защитить имена невиновных в этой катастрофе, я изменил название этой компании на Bell Computers. На следующем слайде показано, как выглядела IT инфраструктура таких компаний в середине 90-х. Это типичная архитектура большого универсального отказоустойчивого сервера HP Tandem Mainframe для функционирования магазина компьютерной техники.



Им нужно было построить систему управления всеми заказами, продажами, возвратом, каталогами продуктов, клиентской базой, так что они выбрали самое распространенное на то время решение мейнфрейма. Эта гигантская система содержала в себе каждую крупицу информации о компании, все, что только можно, и любая транзакция проводилась через этот мейнфрейм. Они держали все свои яйца в одной корзине и считали, что это нормально. Единственное, что сюда не вошло это каталоги почтовых заказов и оформление заказов по телефону.

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

Первоначальный дизайн выглядел довольно симпатично и состоял из сайта верхнего уровня bell.com и ряда поддоменов для отдельных приложений: каталога catalog.bell.com, аккаунтов account.bell.com, заказов orders.bell.com, поиска товаров search.bell.com. Каждый поддомен использовал фреймворк ASP.Net 1.0 и собственные базы данных, и все они общались с бэкендом системы. Однако все заказы продолжали обрабатываться и выполняться внутри единственного огромного мейнфрейма, в котором оставался весь мусор, зато фронтенд представлял собой отдельные веб-сайты с индивидуальными приложениями и отдельными базами данных.



Итак, дизайн системы выглядел упорядоченным и логичным, но реальная система была такой, как показано на следующем слайде.



Все элементы адресовали вызовы друг другу, обращались к API, встраивали сторонние библиотеки dll и тому подобное. Часто случалось, что системы управления версиями хватали чужой код, запихивали его внутрь проекта, и затем все ломалось. MS SQL Server 2005 использовал концепцию линк-серверов, и хотя я не показал стрелками на слайде, каждая из баз данных также общалась друг с другом, потому что как бы нет ничего плохого в том, чтобы строить таблицы на основании данных, полученных из нескольких БД.

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



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

Существующее приложение было в продакшене на протяжении 15 лет, что является рекордным для приложений на базе ASP.Net. Сервис принимал заказы со всего мира, и ежегодная прибыль от этого единственного приложения достигала миллиарда долларов. Значительную часть прибыли формировал именно веб-сайт bell.com. По черным пятницам число заказов, сделанных через сайт, достигало несколько миллионов. Однако существующая архитектура не позволяла никакого развития, поскольку жесткие взаимосвязи элементов системы практически не позволяли вносить в сервис никаких изменений.

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

Они поступили разумно, изучив опыт других компаний, чтобы посмотреть, как те решили аналогичную проблему. Одним из таких решений была архитектура сервиса Netflix, представляющая собой микросервисы, соединенные через API, и внешнюю базу данных.

Руководство Bell Сomputers приняло решение построить именно такую архитектуру, придерживаясь неких основных принципов. Во-первых, они отказались от дублирования данных, используя подход общего доступа к БД. Никакие данные не пересылались, напротив, все, кто в них нуждался, должны были обращаться к централизованному источнику. Далее следовали изолированность и автономность каждый сервис был независим от других. Они решили использовать Web API абсолютно для всего если вы хотели получить данные или внести изменения в другую систему, все это делалось через Web API. Последней важной вещью был новый главный мейнфрейм под названием Bell on Bell в отличие от мейнфрейма Bell, основанного на железе конкурентов.

Итак, в течение 18 месяцев они создавали систему, руководствуясь этими основными принципами, и довели ее до стадии предпродакшена. Вернувшись на работу после выходных, разработчики собрались вместе и включили все сервера, к которым была подключена новая система. 18 месяцев работы, сотни разработчиков, самое современное аппаратное обеспечение Bell и никакого положительного результата! Это разочаровало множество людей, потому что они неоднократно запускали эту систему на своих ноутбуках, и все было нормально.

Они поступили разумно, кинув все деньги на решение этой проблемы. Они установили самые современные серверные стойки со свитчами, использовали гигабитное оптоволокно, самое мощное серверное железо с сумаcшедшим объемом RAM, соединили все это, настроили и снова ничего! Тогда они начали подозревать, что причина может быть в таймаутах, поэтому зашли во все веб-настройки, все настройки API и обновили всю конфигурацию таймаутов до максимальных значений, так что оставалось только сидеть и ждать, когда с сайтом что-то произойдет. Они ждали, ждали и ждали в течение 9 с половиной минут, пока веб-сайт наконец-то загрузился.

После этого до них дошло, что сложившаяся ситуация нуждается в тщательном разборе, и они пригласили нас. Первое, что мы выяснили в течение всех 18 месяцев разработки так и не было создано ни одного реального микро все становилось только еще больше. После этого мы приступили к написанию post-mortem, известного также как regretrospective, или печальная ретроспектива, она же blame storm обвинительный штурм по аналогии с мозговым штурмом brain storm, чтобы разобраться в причине катастрофы.

У нас было несколько улик, одной из которых являлось полное насыщение трафиком в момент вызова API. Когда вы используете монолитную архитектуру сервиса, то сразу можете понять, что именно пошло не так, потому что у вас имеется трассировка к единственному стеку, которая сообщает обо всем, что могло вызвать сбой. В случае, когда куча сервисов одновременно обращаются к одному API, нет никакой возможности отследить трассировку, кроме как использовать дополнительные инструменты сетевого мониторинга типа WireShark, благодаря которым можно рассмотреть отдельный запрос и выяснить, что произошло при его реализации. Поэтому мы взяли одну веб-страницу и на протяжение почти 2-х недель складывали кусочки мозаики, совершая к ней самые различные вызовы и анализируя, к чему приводит каждый из них.
Посмотрите на эту картинку. Она показывает, что один внешний запрос побуждает сервис совершать множество внутренних вызовов, которые возвращаются обратно. Получается, что каждый внутренний вызов совершает дополнительные хопы, чтобы быть способным самостоятельно обслужить этот запрос, потому что не может больше никуда обратиться за получением нужной информации. Эта картинка выглядит бессмысленным каскадом вызовов, поскольку внешний запрос вызывает дополнительные сервисы, которые вызывают другие дополнительные сервисы, и так практически до бесконечности.



Зеленым цветом на этой схеме показан полукруг, в котором сервисы вызывают друг друга сервис А вызывает сервис В, сервис В вызывает сервис С, а тот снова вызывает сервис А. В результате мы получаем распределенный тупик. Единственный запрос создавал тысячу сетевых вызовов API, и поскольку система не обладала встроенной отказоустойчивостью и защитой от зацикливания, то запрос оканчивался неудачей, если хотя бы один из этих API-вызовов давал сбой.

Мы сделали некоторые математические вычисления. Каждый API-вызов имел SLA не более 150 мс и 99,9% аптайм. Один запрос вызывал 200 различных вызовов, и в наилучшем случае страница могла быть показана через 200 х 150 мс = 30 секунд. Естественно, это никуда не годилось. Перемножив 99,9% аптайм на 200, мы получали 0% доступность. Получается, что эта архитектура была обречена на провал с самого начала.

Мы обратились к разработчикам с вопросом, как же они не сумели разглядеть эту проблему на протяжение 18 месяцев работы? Оказалось, что они подчитывали SLA только для запущенного ими кода, но если их сервис вызывал другой сервис, они не считали это время в своих SLA. Все, что запускалось в пределах одного процесса, придерживалось значения 150 мс, но обращение к другим сервисным процессам многократно увеличивало суммарную задержку. Первый извлеченный из этого урок формулировался так: Распоряжаетесь ли вы своим SLA или же SLA распоряжается вами? В нашем случае выходило второе.

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



Если посмотреть на границы сервисов на предыдущей картинке, видно, что все они неправильные. Существует масса источников, которые советуют, как определять границы сервисов, и большинство делают это неправильно, как например, Microsoft на следующем слайде.



Эта картинка из блога MS на тему Как строить микросервисы. Здесь показано простое веб-приложение, блок бизнес-логики и база данных. Запрос поступает напрямую, вероятно, здесь имеется один сервер для веб, один сервер для бизнеса и один для БД. Если увеличить трафик, картинка немного поменяется.



Здесь появляется балансировщик нагрузки для распределения трафика между двумя веб-серверами, кэш, расположенный между веб-сервисом и бизнес-логикой и еще один кэш между бизнес-логикой и базой данных. Именно такую архитектуру использовала компания Bell для своего приложения балансировку нагрузки и blue/green развертывание, выполненное в середине 2000-х. До некоторого времени все работало хорошо, поскольку данная схема предназначалась для монолитной структуры.

На следующей картинке показано, как MS рекомендует осуществлять переход от монолита к микросервисам просто разделить каждый из основных сервисов на отдельные микросервисы. Именно при внедрении этой схемы Bell и совершили ошибку.



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

Однако эта картинка была абсолютно неправильной, потому что не картировала никакие бизнес-единицы вне IT-кластера компании. Данная схема не учитывала никакой связи с внешним миром, так что было непонятно, как, например, получать стороннюю бизнес-аналитику. Замечу, что у них к тому же было несколько сервисов, придуманных просто для развития карьеры отдельных сотрудников, которые стремились управлять как можно большим числом людей, чтобы получать за это больше денег.

Они считали, что для перехода на микросервисы достаточно просто взять их внутреннюю инфраструктуру физического уровня N-tier и вставить в нее Docker. Давайте взглянем, как же выглядит традиционная архитектура N-tier.



Она складывается из 4 уровней: уровень пользовательского интерфейса UI, уровень бизнес-логики, уровень доступа к данным и база данных. Более прогрессивна DDD (Domain-Driven Design), или программно-ориентированная архитектура, где два средних уровня представляют собой доменные объекты и репозиторий.



Я попытался рассмотреть в этой архитектуре различные области изменений, различные области ответственности. В обычном N-tier приложении классифицируются различные области изменений, которые пронизывают структуру вертикально сверху вниз. Это Catalog, настройки Config, выполняемые на индивидуальных компьютерах и проверки Checkout, которыми занималась моя команда.



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

Давайте рассмотрим, что означает быть сервисом. Существует 6 характерных свойств определения сервиса это программное обеспечение, которое:

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

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

Теперь рассмотрим определение микросервисов:

  • микросервис имеет малый размер и предназначен для решения одной конкретной задачи;
  • микросервис автономен;
  • при создании архитектуры микросервиса используется метафора городской планировки town planning metaphor. Это определение из книги Сэма Ньюмана Создание микросервисов.

Определение Bounded Context взято из книги Эрика Эванса Domain-Driven Design. Это основной паттерн в DDD, центр проектирования архитектуры, который работает с объемными архитектурными моделями, разделяя их на разные Bounded Context и явно определяя взаимодействие между ними.



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

Так вот, Bounded Context говорит, что если мы не можем дать однозначного определения тому, что представляет собой потребитель наших услуг, давайте определим границы, в пределах которых можно рассуждать о значении этого термина, а затем определим точки перехода между этими различными определениями. То есть, если мы говорим о клиенте с точки зрения оформления заказов, это означает то-то и то-то, а если с точки зрения продаж то-то и то-то.

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



Итак, мы сказали ребятам из Bell Computers: Мы не сможем исправить ничего в созданном вами хаосе, потому что у вас просто не хватит для этого денег, но мы исправим всего один сервис, чтобы придать всему этому смысл. С этого места я начну рассказ о том, как мы исправили единственный сервис, чтобы он стал отвечать на запросы быстрее, чем через 9 с половиной минут.

22:30 мин

Продолжение будет совсем скоро


Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

I see hey, stop moving как зрительная система компенсирует неточности саккад

17.06.2020 10:12:43 | Автор: admin


Одним из самых важных органов чувств считаются глаза. Благодаря им мы получаем львиную долю информации об окружающем мире. Когда мы рассматриваем что-то, наш взор не фиксированный, т.е. наши глаза совершают множество мелких движений, именуемых саккадами. Из-за этих движений смещается сетчатка, что в свою очередь снижает четкость изображения (вспомните не самые удачные фильмы в стиле мокьюментари). Чтобы компенсировать этот эффект, зрительная система снижает свою чувствительность к смещению зрительных стимулов во время саккад. Однако до сего времени механизмы, лежащие в основе этого тонкого процесса, оставались не изучены. Посему ученые из университета Тохоку (Япония) решили провести ряд практических опытов и моделирований. Что показали эксперименты, какие секреты таит в себе гашение саккадического смещения, и почему так важны визуальные стимулы до и после саккад? Ответы на эти вопросы мы найдем в докладе ученых. Поехали.

Основа исследования


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

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


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

Чего не хватает сетчатке, так это однородности: большая часть зрительного поля связана с периферическим зрением и лишь небольшая центральная часть отвечает за основное (сфокусированное) зрение. Разница между этими областями очевидна: периферическое зрение имеет меньшее пространственное разрешение, чем центральное. Следовательно, чтобы эффективно собирать визуальную информацию, глаза должны двигаться.

Эти движения, как уже говорилось ранее, называют саккадами и совершаются глазом несколько раз в секунду. За счет саккад мы меняем точку фиксации нашего взгляда, за счет его осуществляется рассматривание объекта интереса, т.е. сбор визуальной информации.

Саккады работают во всех направлениях (вверх-вниз, влево-вправо), однако наибольшее число движений происходит в горизонтальной плоскости. А диапазон саккад варьируется от 2 до 15.


Саккады во время поворота глаза.

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

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

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

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

Потому ученые и предполагают, что механизм оценки саккад-индуцированного сдвига в изображении на сетчатке основан на копии эфферентной* моторной команды движения глаза для компенсации сдвигов изображения.
Эфферентные* (двигательные) нейроны передают импульс ЦНС рабочим органам.
После перенастройки местоположения стимула в пространстве механизм может интегрировать изображения сетчатки до и после саккад. Тем не менее, поскольку фактическая амплитуда саккады и амплитуда саккады, предсказанная на основе эфферентной копии, не всегда одинаковы, объект может восприниматься как смещенный во время саккады даже без физического смещения, если визуальная система полностью доверяет копии.

Решение этой проблемы заключается в том, что зрительная система намеренно не фиксирует небольшие смещения объекта во время саккады, даже если их легко обнаружить во время фиксированного рассмотрения. Этот феномен называют саккадным подавлением смещения (SSD от saccadic suppression of displacement).

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

Еще одним важным элементом в исследовании визуальной стабильности является эффект гашения (blanking effect).

Эффект гашения это явление, при котором эффективность обнаружения смещения объекта во время саккады улучшается за счет вставки временного пробела (50300 мс) во время саккады и до того, как объект вновь появляется в новой позиции. Это явление предполагает, что сигналы о смещении объекта действительно доступны после саккады, но не могут использоваться для обнаружения смещения, когда объект саккады присутствует в ее конце, т.е. без пост-саккадического пробела. Смещение, однако, может быть воспринято, когда подавление устраняется путем вставки пост-саккадического пробела.

Эффект гашения поддерживает предположение о том, что SSD является активным процессом, позволяющим избежать любого ошибочного восприятия смещения, вызванного неточными саккадами и/или неточными копиями эфферентных команд саккады, поскольку оно демонстрирует, что имеется достаточно информации для обнаружения смещения после саккад.

В ранее проведенных исследованиях было установлено, что магноцеллюлярный зрительный путь (М-путь), который реагирует на стимулирующее движение, избирательно подавляется во время саккад, как и низкоуровневые движения. Гашение или удаление объекта сразу после саккады активирует механизм, который подавляет М-путь во время саккады.

Также считается, что важную роль в механизме саккад играет контрастность объекта рассмотрения. Чтобы проверить это, ученые провели анализ влияния контраста до- и после-саккадического обэекта на обнаружение смещения.

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

Было установлено, что обнаружение смещения было лучше, если объект до саккады имел более высокую контрастность. А вот увеличение контрастности объекта после саккады приводило к ухудшению восприятия в обычных условиях, но не в случае применения эффекта гашения.

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

Подготовка к опытам


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

Участниками наблюдений стали 8 мужчин и 2 женщины в возрасте от 21 до 24 лет с нормальным зрением. Каждый из участников размещал голову на специальной подставке (как в кабинете офтальмолога) на расстоянии 45 см от объекта, демонстрируемого на ЭЛП-экране (Sony GDM-F520, 21, 100 Гц).

Положение глаз измерялось с помощью устройства слежения за лимбом*, состоящего из инфракрасного диода и двух фотодиодов.
Лимб роговицы* место соединения роговицы и склеры, т.е. край роговицы.
Положение глаз и скорость их движения оценивались в реальном времени посредством алгоритма разности трех точек, в котором скорость в момент времени n рассчитывалась исходя из положения глаза в момент времени n-1 и момент времени n+1.

Начало саккады определялось как момент, когда скорость глаза превышала 30 /с. Обнаружение начала саккады всегда задерживалось на 1 кадр (10 мс) из-за метода расчета скорости.


Условия опытов: А опыты без применения временных пробелов; В опыты с временными пробелами (эффект гашения).

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

Расчеты показали, что исчезновение предсаккадического объекта происходит примерно за 32 мс до самой саккады. Лишь в 0.7% опытов объект исчезал после саккады. Также в дальнейшем моделировании не учитывались результаты опытов, где саккада была короче 120 мс или дольше 400 мс. Суммируя все уточнения и исключения, было забраковано лишь 6% результатов опытов.

Также необходимо было провести калибровку перед каждым опытом. В начале калибровки пять одинаково разделенных точек были представлены последовательно вдоль горизонтальной линии, тогда как центральная точка была всегда расположена в центре дисплея. Участникам необходимо было фиксироваться на каждой точке по очереди и нажимать кнопку, когда каждая фиксация была завершена. Если коэффициент регрессии* был меньше 0.9, процедуру калибровки повторяли до тех пор, пока критерий не был удовлетворен.
Коэффициент регрессии* показывает силу и характер влияния независимых переменных (в данном случае 5 точек) на зависимую.
В качестве объектов (точка фиксации взгляда, объект до и после саккады), за которыми должны были наблюдать участники опытов, выступали диски диаметром 0.88. Фоновая яркость была постоянной и составляла 21.4 кд/м2 (кандел на метр квадратный). Перед проведением опытов также был измерен контраст. В данном случае это был контраст Вебера, который является отношением объекта к фону, и поэтому в некоторых случаях контраст превышал 100%. Чтобы учесть разницу в чувствительности между центральным и периферическим зрением, контрасты стимула определялись факторами порогового контраста.

Контраст до-саккадического объекта в 3, 4.3, 6.1, 8.8, 12.6 или 18 раз превышал порог контраста при периферическом зрении, а у пост-саккадического в 3, 4.3, 6.1, 8.8, 12.6 или 18 раз превышал порог контрастности при центральном зрении.

Результаты опытов и моделирования


Первым делом стоит определить, каково же влияние контраста на обнаружение смещения.

Сначала участникам опытов необходимо было выполнить саккаду вправо под углом 17.8 от точки фиксации взгляда до объекта (диска). Как только начиналась саккада, объект в первоначальной позиции исчезал и появлялся на 0.33 вправо или влево сразу (без временно пробела) или с задержкой в 100 мс (эффект гашения). Основная задача участников сказать куда сместился объект (влево или вправо). Значение контраста объекта до и после сакадды варьировалось в ходе опытов.


Изображение 1: влияние контраста до и после саккады на точность обнаружения смещения при обычных условиях (без эффект гашения).

Точность обнаружения смещения объекта через саккаду выражалась как d в каждом контрастном состоянии. Значения d в условиях отсутствия/наличия временных пробелов показаны на изображениях 1 и 2 соответственно.


Изображение 2: влияние контраста до и после саккады на точность обнаружения смещения при использовании временного пробела (эффект гашения).

В состоянии без временного пробела точность обнаружения смещения значительно снизилась с постсаккадическим контрастом (1C), а с досаккадическим контрастом наоборот улучшилась ().

В режиме с временным пробелом точность обнаружения смещения улучшалась при контрасте до саккады (), но никак не менялась от контраста после саккады ().

Факт того, что повышение контраста до саккады улучшает обнаружение смещения объекта, полностью согласуется с классическим представлением о работе глаз человека: чем сильнее первичный стимул, тем лучше будет его дальнейшее обнаружение. А вот снижение точности глаз из-за повышения контраста объекта после саккады подразумевает, что постсаккадический стимул усиливает SSD (саккадное подавление смещения).

Для лучшего понимания связи между SSD и контрастности ученые провели моделирование.

Информация от сетчатки передается в зрительную кору по двум основным функционально отличным путям: магноцеллюлярный путь (M-путь) и парвоцеллюлярный путь (P-путь). Психофизические исследования показали, что M-путь сильно подавлен во время саккад.

Получается, что информация о яркости объекта, представленного сразу после саккады, сильно влияет на эффективность обнаружения смещения, как если бы подавление M-пути было еще больше усилено увеличением контрастности.

Если М-путь подавлен во время саккад, то Р-путь должен быть доминантным сразу после саккад. Это значит, что постсаккадическая информация от сетчатки обрабатывается главным образом через P-путь. Снижение точности с увеличением постсаккадического контраста наталкивает на мысль, что активность P-пути подавляет обнаружение смещения.

Чтобы проверить эту теорию, ученые создали модель, основанную на предположении, что P-путь доминирует сразу после саккады.

Если предположить, что существует только два визуальных пути от сетчатки до коры (игнорируя все остальные), одна из самых простых моделей будет состоять в том, что сигналы M-пути подавляются сигналами из P-пути или визуальных областей более высокого уровня, которые получают входной сигнал от P-пути.

Отклик каждого пути на контраст был выражен функцией, которая также используется для моделирования контрастного ответа ЛКТ* клеток М- и Р-типа и для сравнения с психофизическими результатами опытов.
ЛКТ* (латеральное коленчатое тело) структурная часть мозга, расположенная на нижней латеральной стороне подушки таламуса.
Для оценки выходного сигнала обнаружения смещения была использована модель Рейхардта, с помощью которой была рассчитана корреляция между пред- и постсаккадическими сигналами, косвенно связанными с M-путем.


Модель Рейхардта для оценки обнаружения смещения объекта.

Если утрировано, то в данной модели от значения отклика Р-пути зависела сила выходного сигнала всей модели (чем выше отклик Р-пути, тем ниже отклик всей модели).

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



k pre нормализованный контраст объекта до саккады;
kpost нормализованный контраст объекта после саккады;
параметры и контраст полунасыщения и сила зависимости от контраста;
R коэффициент, используемый для преобразования отклика в точность обнаружения смещения;
n0 константная нелинейная функция, моделирующая нейронные контрастные характеристики, которая контролирует уровень шума;
m и p M-путь и P-путь;
S вклад отклика P-пути, который влияет на обнаружение смещения;
SBlank вклад отклика P-пути в случае использование эффекта гашения (т.е. временного пробела).


Таблица 1: подогнанные параметры модели. Числа показывают параметры, полученные путем подгонки предлагаемой модели к данным точности обнаружения смещения, усредненным по всем участникам опытов.


Изображение 3: результаты моделирования.

Согласно таблице 1, функция P-пути имеет более низкий контрастный отклик и меньший контраст полунасыщения, чем функция M-пути, что соответствует разнице в (p в 2.4 раза больше, чем m). Это согласуется с разницей между характеристиками контрастного отклика ЛКТ клеток P- и M-типа, о которых сообщалось в ранее проведенных исследованиях: контраст полунасыщения ЛКТ клеток P-типа приблизительно в 5 раз больше, чем у клеток M-типа.

Результаты моделирования полностью согласуются с гипотезой о разном влиянии двух путей на обнаружение смещения. Таким образом, Р-путь вносит положительный вклад в саккадное подавление смещения, а М-путь способствует обнаружению смещения объекта.

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

Эпилог


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

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

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

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

Опыты и моделирование также показали, что каждый из нейронных путей, затронутых в исследовании, играет свою роль в составлении визуальной картины того, что мы видим. М-путь отвечает за обнаружение смещения объекта, а Р-путь подавляет ошибочную информацию, вызванную саккадами. Таким образом, эффект SSD (саккадное подавление смещения) вступает в силу, когда сигнал Р-пути подавляет сигнал М-пути сразу после саккады. В противном случае информация содержала бы неточности (утрировано говоря, представьте себе ситуацию, когда человек двигается во время фотосъемки).

Зрительная система не только крайне важна для человека, поскольку позволяет получать большую часть информации об окружающем мире, но и крайне сложна. Наши глаза постоянно получают новую информацию. Даже если мы будем смотреть на один и тот же объект, наша сетчатка продолжает двигаться (саккады), собирая данные об объекте. И за счет того, что одни подсистемы собирают данные, а другие отфильтровывают ненужные и ложные, мы видим мир таким, каков он есть.

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

Благодарю за внимание, оставайтесь любопытствующими и хорошей всем рабочей недели, ребята. :)

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Карусель из 16 атомов самый маленький молекулярный ротор в мире

19.06.2020 10:21:33 | Автор: admin


На микро- и нанометровом уровне происходит множество интереснейших процессов, о которых мы даже не подозреваем, ибо их не так и просто увидеть. Чего стоит наше собственное тело: миллионы клеток из разных подсистем слаженно выполняют свои функции, поддерживая жизнедеятельность организма. Среди великого разнообразия необычных молекулярных образований стоит выделить молекулярные моторы, к которым причисляют моторные белки (например, кинезин). Концепция искусственных молекулярных моторов существует еще с середины прошлого века, а попыток создать нечто подобное было очень много, и все они чем-то отличались от других. Сегодня мы с вами познакомимся с исследованием, в котором ученые из EMPA (Швейцарская федеральная лаборатория материаловедения и технологий) создали молекулярный двигатель из 16 атомов, что делает его самым маленьким на данный момент. Как именно ученые создавали нано-двигатель, какие его особенности и возможности, и как эта разработка может быть применена на практике? Об этом мы узнаем из доклада ученых. Поехали.

Основа исследования


В 1959 году американский ученый Ричард Фейнман (1918-1988) высказал теорию о том, что когда-то мы сможем создавать молекулярные моторы. Кому-то эта идея на то время могла показаться безумной, но скептическое отношение к науке еще никогда никого не останавливало.

Основной механизм молекулярных моторов это вращение, за что их еще именуют молекулярными роторами. В 1999 году Т. Росс Келли и его коллеги опубликовали доклад (Unidirectional rotary motion in a molecular system), в котором описывалось ротационное движение молекулярной системы посредством химических процессов.


Профессор органической химии Бостонского колледжа Т. Росс Келли.

Система состоит из трехлопастного триптиценового ротора и геликена и может выполнять однонаправленное вращение на 120. Чтобы выполнить это вращение, системе необходимо пройти 5 этапов.


Молекулярный ротор Келли (схема 5-этапного вращения).

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

Тем не менее, метод Келли показывает, что химическая энергия может быть использована для создания искусственных молекулярных моторов.

В том же 1999 году в университете Гронингена (Нидерланды) под руководством Бена Феринга был создан еще один молекулярный мотор (Light-driven monodirectional molecular rotor). Их вариант мог вращаться на 360 градусов и состоял из бис-хелицина, соединенного двойной аксиальной связью и имеющий два стереоцентра.


Молекулярный ротор Феринга (схема 4-этапного вращения).

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

В 2008 году в университете штата Иллинойс (США) Петр Крал с коллегами разработали молекулярный мотор, движение которого осуществляется за счет резонансного или нерезонансного туннелирования электронов (Nanoscale Rotary Motors Driven by Electron Tunneling).


Молекулярный мотор Крала (схема вращения за счет туннелирования электронов).

Туннелирование электронов обеспечивает мотор энергией, необходимой ему для движения. Сам мотор состоит из 3 (или 6) лопастей, образованных на основе полимеризированного ицеана. В качестве оси мотора используется углеродная нанотрубка.

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

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

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

Ученые решили использовать эту концепцию, но слегка изменив ее. В качестве хирального статора* было решено использовать поверхность нецентросимметричных кристаллов PdGa (Pd палладий, Ga галлий).
Статор* неподвижная часть мотора, взаимодействующая с ротором (подвижная часть мотора).
Это ослабляет геометрические ограничения на молекулу ротора и позволяет реализовать направленное движение даже для простых и симметричных молекул, таких как C2H2.

На Pd3 молекулы ацетилена адсорбируются поверх тримеров Pd. Во время STM-визуализации при 5 К они выглядят как гантели с разнесением между лепестками около 3 в трех симметрично эквивалентных ориентациях, повернутых на 120 (1E-1G), между которыми они переключаются квазимгновенно (1C и 1D).


Изображение 1

Молекулы ацетилена прочно закреплены на тримере и обычно диссоциируют* перед тем, как их вытаскивают из тримера с помощью иглы микроскопа.
Диссоциация* распад сложных химических соединений на составляющие компоненты.
Ученые наблюдали за процессом вращения, записывая временной ряд туннельного тока IT(t) при фиксированном положении иглы (1H).

IT(t) на графике 1H, записанный в течение t = 100 с, демонстрирует последовательности циклических скачков между тремя уровнями ( .RA RB BC RA ) с nCCW= 23 и nCW= 0 (CCW против часовой стрелки, CW по часовой стрелке). Это приводит к частоте f = nCCW + nCW / t = 0.23 Гц и идеальной направленности dir = 100% (nCCW-nCW) / (nCCW + nCW) = 100%.

СМТ снимки показывают, что в движении мотора преобладает направление против часовой стрелки.


Изображение 2

Анализ параметрической зависимости частоты вращения (2A-2C) показывает, что этот молекулярный двигатель работает в двух различных режимах: режим туннелирования (TR), где его частота вращения T не зависит от температуры (T < 15 K), напряжения смещения ( |VG| < 30 мВ) и тока (IT < 200 пА); классический режим (CR), где частота вращения зависит от этих параметров.

Экспериментальные данные (изображение 1) были записаны в режиме TR, однако ученые решили сначала рассмотреть именно классический режим, где вращения C2H2 могут избирательно подпитываться от тепловых или электрических возбуждений.

Для начала была найдена температурная зависимость частоты вращения при низком смещении (), чтобы следовать характеристике Аррениуса* (сплошная линия на ): (T) = T + Аexp (- EB / kBT), где T = 4.5 Гц, А = 10 8.72.0 Гц, EB = 27.57.1 мэВ.
Уравнение Аррениуса* устанавливает зависимость константы скорости химической реакции от температуры.
Выше 30 мВ частота увеличивается экспоненциально с VG, независимо от полярности (2B и 2C). В тех же условиях, но при постоянном напряжении смещения, степенная зависимость* ( InT при n 1; 2D) идентифицирует электронно-стимулированное вращение как одноэлектронный процесс. Зависимость частоты и направленности вращения от параметров T, VG и IT хорошо воспроизводится кинетической моделью Ланжевена (сплошные линии на 2B и 2C).
Степенной закон* относительное изменение одной величины приводит к пропорциональному относительному изменению другой величины.
Ученые отмечают, что важную роль в анализе всей системы играет понимание влияния иглы микроскопа, необходимого для фактических наблюдений за движением. В частности, необходимо убедиться, что нарушение симметрии инверсии из-за положения иглы вблизи двигателя не преобладает над влиянием хиральной подложки при определении направления вращения.

Для этого было измерено 6400 временных рядов с постоянной высотой наконечника zT(t) на 80х80 сетке из равноудаленных точек 1х1 нм2 в окрестности отдельных молекул ацетилена в режиме туннелирования (2E). К счастью, анализ показал, что игла микроскопа никак не влияет на однонаправленное вращение молекулы.

Дополнительное моделирование, в ходе которого была выполнена оптимизация конфигурации молекулы и формы иглы, позволило получить идеальную последовательность (схему) сигналов (2F). Следовательно, независимо от положения иглы последовательность сигналов всегда соответствует вращению против часовой стрелки.

Кроме того, как видно на 2G, нет явной зависимости T от положения иглы. Потому можно предположить, что все три вращательные конфигурации C2H2 будут энергетически эквивалентными. Три вращательных состояния становятся энергетически невырожденными, только если игла поднесена слишком близко к подложке.

Оценив 1792 событий вращения (nCCW= 1771 и nCW = 21) в режиме туннелирования, была определена направленность dir 96.7% с достоверностью 2. Сопоставив результаты моделирования и экспериментов удалось определить вращение C2H2, описать которое можно как вращающийся ротор, центр масс которого движется по окружности с радиусом r = 0.5 0.1 и моментом инерции IC2H2 = 5.62 х 10-46 кгм2 ().


Изображение 3

Установив степень влияния иглы микроскопа на вращение системы, ученые приступили к детальному рассмотрению зависимости вращения от параметров системы (3A-3D). Температурная зависимость показывает быстрое падение направленности, когда термически активированные вращения начинают вносить значительный вклад. Сплошная линия на предполагает, что T имеет 98%-ную направленность, тогда как термически активированные скачки, описываемые уравнением Аррениуса, являются чисто случайными.

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

При T = 5 K уменьшение направленности также наблюдается для напряжений смещения VG выше 35 мэВ (3B). Однако, в отличие от тепловых вращений, те, которые вызваны неупругим туннелированием электронов (IET), становятся ненаправленными постепенно. Это отчетливо наблюдается в режиме, когда сосуществуют тепловые и IET-вращения. Как показано на 3C, независимая от напряжения направленность (10% при T = 19 K и |VG| < 30 мВ) может быть значительно увеличена при более высокой |VG| из-за дополнительных направленных вращений IET. Однако это увеличение эффективно только в узком диапазоне напряжений, за пределами которого (в большую сторону) направленность быстро уменьшается.

В отличие от этого, IT-зависимость направленности для фиксированного напряжения является слабой (3D), где небольшое уменьшение направленности с увеличением тока объясняется обнаружением двух быстро последовательных вращений против часовой стрелки как одного ошибочного непрерывного вращения. (сплошные линии на 3D). Из этого следует, что направленность остается выше 95% при |VG| < 40 мВ даже при высоком токе.

Для моделирования кинетики происходящих событий в данной системе было решено использовать концепцию смещенного броуновского движения*, предложенную в исследовании Астумяна (The Physics and Physical Chemistry of Molecular Machines) и Хэнджи (Artificial Brownian motors: Controlling transport on the nanoscale).
Броуновское движение* беспорядочное движение частиц твердого вещества, вызванное тепловым движением частиц жидкости или газа.
В полученной модели IET-индуцированного вращения предполагается статический и периодический, но асимметричный потенциал U() ( = [0.2] с периодичностью /3) с асимметрией потенциала (Rasym, вставка на ).

Одно IET события достаточно для мгновенного возбуждения молекулы из ее основного состояния, а ее траектория (t) получается из динамики Ланжевена: I = (U() / ) , где I момент инерции, а коэффициент вязкой диссипации.

В зависимости от Rasym и , две разные минимальные кинетические энергии EL и ER требуются для преодоления барьера слева (т.е. для движения по часовой стрелке) и справа (т.е. для движения против часовой стрелки) соответственно. Эти энергии являются основой для описания частоты и направленности с помощью использованной кинетической модели.

Сравнение кинетической модели и результатов экспериментов ( и ) позволяет определить зависящие от температуры EL(T) и ER(T) (3E). В результате было установлено, что Rasym равен 1.25 < Rasym < 1.5, предполагая, что EB = 25 мэВ.

Уменьшение диссипации с 1.6 х 10-33 кгм2/с при 5 К до 1.1 х 10-33 кгм2/с при 20 К можно объяснить менее эффективным связыванием молекулы с подложкой при повышении температуры.


Изображение 4

На графике показаны последовательности IT(t) для C2H2, C2DH и C2D2, где отчетливо видно отношения T (по отношению к C2H2) 1:0.56(11):0.24(5) (C2H2:C2DH:C2D2), которые наблюдались при использовании разных игл микроскопа.

Это явное относительное уменьшение T контрастирует со сравнительно небольшим относительным изменением момента инерции 1:1.08:1.2 и, следовательно, показательно для квантового туннелирования.

Рассмотрение IT(t) последовательности C2DH с нарушенной C2 симметрией показывает, что вращение протекает через шесть, а не три уровня тока (4B). Это является доказательством того, что для полного вращения ацетилена действительно требуется шесть вращений против часовой стрелки на 60. Сравнение экспериментальных и смоделированных значений T показало идеальное совпадение (4D).

Квантовые туннельные вращения, сопутствующие высокой направленности в 97.7%, позволяют оценить изменение энтропии одиночного туннельного вращения по экспериментально полученным вероятностям вращения против часовой стрелки и по часовой стрелке, определяемым как S = kBln (ppCCW / pCW) kBln (100/1) 0.4 мэВ/К.

Это означает, что направленное вращение в режиме туннелирования должно быть неравновесным процессом с диссипацией энергии Q > 2 мэВ при 5 К и Q > 6 мэВ при 15 К на вращение.

Максимальная мощность рассеяния составила 100 мэВ/с на каждый ротор, а частота туннелирования составила максимум 10 Гц. Однако микроскоп, необходимый для наблюдений, локально рассеивает около 3 х 106 мэВ / с даже при самых низких настройках туннельного тока. Несмотря на столь экстремальные настройки, наблюдается постоянная частота вращения со стабильно высокой направленностью.

В заключение ученые отмечают, что высоконаправленное вращение C2H2 на хиральных поверхностях PdGa{111}Pd3 демонстрирует богатую феноменологию, наиболее заметно характеризующуюся беспрецедентно высокой направленностью и малым размером мотора.

Ротор (C2H2) и статор (кластер Pd3-Ga6-Pd3) состоят всего лишь из 16 атомов, образуя однонаправленный шестизначный циклический молекулярный двигатель (), который непрерывно работает, получая энергию исключительно от одиночных электронов.

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

Эпилог


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

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

Благодарю за внимание, оставайтесь любопытствующими и отличных всем выходных, ребята!

Пятничный офф-топ:

Каждый раз, когда я читаю что-то про молекулярные моторы, я вспоминаю это видео (да, оно не ново, но улыбку вызывает постоянно).

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Умная одежда устройство модуляции температуры на основе графена

24.06.2020 10:13:26 | Автор: admin


У природы нет плохой погоды, как поется в знаменитой песне из кинофильма Служебный роман. Однако далеко не все готовы согласиться с этим утверждением. Кому-то нравится холод, кто-то предпочитает жару, кому-то все равно. Я же отношусь к тем людям, которые будут жаловаться и на жару, и на холод, нам подавай комфортные +20 C. К сожалению, не всегда и не у всех любителей нейтрального климата есть возможность жить в регионах, где он есть. Сейчас лето в самом разгаре, удушающая жара лишь изредка прерывается кратковременными грозами, которые не особо помогают. Если природа не готова идти нам навстречу, значит стоит делать что-то самим. Сегодня мы познакомимся с исследованием, в котором ученые из Манчестерского университета (Великобритания) разработали умную адаптивную ткань, способную снижать температуру тела человека ее носящего в жаркие дни. Что легло в основу умной ткани, как протекал процесс разработки, и какие дополнительные свойства и варианты применения имеются у этого изобретения? Ответы на эти вопросы мы найдем в докладе ученых. Поехали.

Основа исследования


Прежде, чем рассказать нам о своем творении, ученые отмечают, что прогресс в области пользовательской электроники за последние годы идет семимильными шагами. Буквально каждый день появляется что-то новенькое и необычное. Тем не менее, существует ряд ограничений, которые мешают тем или иным разработкам перейти от стадии лабораторных тестов к стадии массового производства. В аспекте производства умных тканей основной проблемой является сложность интеграции электронных / оптических материалов внутрь волокон ткани. Самый простой вариант в носимой электронике это создание отдельных гаджетов (браслеты, часы и т.д.), которые не требуют внедрения в другую систему (в данном случае, ткань), но спектр возможностей этих устройств будет ограничен.

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

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

Тепловое излучение от многослойного графена может модулироваться электрически через интеркалирование* ионов.
Интеркаляция* обратимое внедрение молекулы или группы молекул между другими молекулами или группами молекул.
В данном исследовании ученые представляют нашему вниманию технологию оптического текстиля, основанную на интеграции в текстиль динамических инфракрасных устройств на базе электрически перестраиваемого графена, образованного методом химического осаждения из паровой фазы (ХОПФ).

Результаты исследования


Устройства состоят из объединенных слоев инфракрасно прозрачного полимерного слоя, многослойного графена, выращенного с использованием метода ХОПФ, слоя тканевого разделителя и проводящей ткани (схема устройства на ).


Изображение 1

Изготовление начинается с выращивания многослойных графеновых пленок на никелевой фольге. Тонкая полиэфирная (PE) пленка, которая функционирует как прозрачный для инфракрасного излучения защитный слой, ламинируется на многослойный графен перед травлением Ni-фольги. Графен на полиэфирном листе прикрепляется к ткани с помощью термоплавкого клея.

Одним из важных моментов данной разработки является удобство использования и практичность, потому необходимо было удостовериться в хорошей адгезии между графеном и подложкой (тканью). Это было сделано посредством нескольких циклов стирки и посредством испытаний на механическое сжатие.

Далее на задний электрод (проводящая ткань) был нанесен ионный жидкий электролит (BMIMPF6), который впоследствии диффундировал в текстильную подложку. Текстиль действует как разделитель и ионопроводящий слой, обеспечивая ионное движение, когда разность напряжений приложена к графену и заднему электроду.

На 1b показаны примеры изготовленных устройств на натуральных (хлопок) и синтетических текстильных материалах (полиэфир).

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

Массив задних электродов и проводку на текстиле изготовили с помощью фотолитографии с последующей металлизацией и процессом отрыва*.
Отрыв* в технологии микроструктурирования представляет собой способ создания структур целевого материала на поверхности подложки с использованием жертвенного материала (например, фоторезиста).
Полученные пиксельные электроды позволяют определять динамические инфракрасные структуры на непрерывном графеновом слое с помощью выборочной интеркаляции.

Принцип работы устройств основан на обратимой интеркаляции ионов в графеновые слои и модулировании его электрических и оптических свойств. При 0 В многослойный графен имеет высокое инфракрасное поглощение, что приводит к высокой излучательной способности, раскрывая фактическую температуру устройства ().


Изображение 2

При подаче достаточной разности напряжений (> 2.5 В) ионная жидкость интеркалирует в слои графена, увеличивая оптическую проводимость и подавляя излучательную способность, тем самым скрывая фактическую температуру устройства. Термографы устройства записывались с помощью длинноволновой инфракрасной камеры, которая визуализирует изображения по закону Стефана-Больцмана:
P = T4
где P количество падающего теплового излучения на матрице болометров*; излучательная способность поверхности; постоянная Стефана-Больцмана; T температура поверхности в Кельвинах.
Болометр* тепловой приемник излучения (преобразует энергию поглощенного электромагнитного излучения в тепловую).
Текстильные устройства находясь непосредственно в тепловом контакте с источниками тепла, такими как тело человека, для предотвращения ложного экранирования температуры источника. Кроме того, графен функционирует как слой с высокой теплопроводностью, который удваивает температуропроводность в плоскости текстиля, улучшая теплопроводность от источника к поверхности.

Временной отклик устройств был получен путем записи видео тепловизором, чтобы получить изменение видимой температуры поверхности (2b).


Динамическое изменение инфракрасного излучения на хлопковом устройстве.

Полная интеркаляция (подавление излучательной способности) занимает ~5 с, когда ток устройства не ограничен. Стоит отметить, что эти измерения проводились в лабораторных условиях (21 C), ограничивающих минимальную кажущуюся температуру.

Устройства могут многократно циклически переключаться между состояниями с высокой и низкой излучательной способностью (2c), однако превышение электрохимического окна электролита ухудшает рабочие характеристики устройства.

Модуляция излучательной способности определялась количественно с помощью измерений отражения в инфракрасном и ближнем инфракрасном диапазонах с использованием инфракрасного Фурье-спектрометр (FTIR), оборудованного интегрирующей сферой. При 0 В коэффициент отражения внутреннего устройства почти плоский (2d) и составляет около 30%, за исключением поглощения в верхней полиэфирной пленке на длинах волн ~3.4, ~6.8, ~13.9 мкм и поглощения в атмосфере (например, CO2, H2O).


Демонстрация работы адаптивного инфракрасного текстильного устройства.

В диапазоне спектральной чувствительности тепловой камеры (8-13 мкм) такие поглощения минимизируются благодаря тщательному выбору верхней защитной пленки. Коэффициент излучения (или коэффициент поглощения) рассчитывается как 1 R, где R коэффициент отражения, поскольку свет не проходит через устройство. По мере того, как ионы интеркалируют графеновые слои, энергия Ферми и оптическая проводимость графена увеличиваются, тем самым увеличивая коэффициент отражения инфракрасного излучения.

Средняя излучательная способность устройства в диапазоне длин волн 8-13 мкм достаточно высока ( 0.7) для 0 В и поддерживается в таком значении до порогового напряжения ( 2.5 В) с последующим резким падением до 0.35 при > 4 В (), что отлично согласуется с термограммами на 2а.

Модуляция излучательной способности охватывает как длинноволновый инфракрасный (8-13 мкм), так и средневолновый инфракрасный (MWIR, 3-5 мкм) диапазон. В MWIR, тем не менее, полиэфирная пленка демонстрирует значительное поглощение из-за режима растяжения C-H связей, который не зависит от приложенного напряжения, ограничивая диапазон модуляции излучательной способности до 0.7-0.5 (2e). Из этого следует, что любые устройства, работающие в этом диапазоне длин волн, нуждаются в нестандартном защитном слое.

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

Также наблюдалась модуляция излучательной способности (0.2-0.4) и в коротковолновом инфракрасном диапазоне (SWIR, 0.9-1.7 мкм). А вот модуляция в видимом спектре была незначительной из-за недостаточного легирования графена.

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

Учитывая, что ткань должна быть растяжимой и гибкой, используемые графеновые элементы должны действовать соответственно. Однако многослойный графен не растягивается и не гнется ввиду механического воздействия. Потому в разработке была использована нестандартная изогнутая конструкция графена, что обеспечило уровень деформации до 60%.


Изображение 3

Решить все проблемы с гибкостью и механическим напряжением можно за счет использования массивов электродов, в не единого элемента. На показан пример такого варианта конфигурации с массивом из 25 индивидуально адресуемых электродов и датчиком термобатареи. В качестве активного слоя использовался большой цельный лист многослойного графена на хлопчатобумажной ткани (3b). Каждый электрод контролирует излучательную способность площадью 2х2 см. Внешняя электронная схема была запрограммирована реагировать на тепловую сигнатуру от датчика. Графики 3c и 3d показывают сигналы датчика и кажущуюся температуру активного пикселя (область контроля 2х2).

Мультипиксельное текстильное устройство отображает буквы C или H (обозначающие cold и hot), настраивая излучательную способность соответствующих пикселей, реагирующих на наличие/отсутствие горячего объекта над датчиком. На 3e показаны тепловые изображения работы устройства при взаимодействии с рукой человека.

Далее ученые провели фактическое практическое испытание устройства, внедренного в обычную футболку. Из-за естественной температуры тела, в условиях окружающей среды, человеческое тело излучает около 100 Вт инфракрасного света в основном в LWIR диапазоне. Этот спектральный диапазон также совпадает с окном атмосферного пропускания, которое позволяет распространять излучаемый LWIR свет на большие расстояния.

Устройство для футболки было изготовлено путем ламинирования пленки графен/полиэфир размером 6х6 см непосредственно на поверхности футболки из 100% хлопка и сеткой из нержавеющей стали на обратной стороне ().


Изображение 4

Для передачи закодированного сигнала был использован микроконтроллер, который был запрограммирован передавать буквы N, G и I азбукой Морзе. Тире и точки создавались путем подавления кажущейся температуры на длительное (9 с) и короткое (3 с) время.

На 4b и показаны инфракрасные снимки футболки в состояниях с высокой и низкой излучательной способностью, а шкала справа показывает зарегистрированную с расстояния в 3 м кажущуюся температуру.

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

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


Передача букв N, G и I азбукой Морзе.

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


Увеличение отражающей способности полиэфирного устройства в ближнем инфракрасном диапазоне.

Разработанное устройство требует низкого напряжения (~ 3 В) и совсем немного энергии (5.5 х 10-4 мАч/см2 на одно событие интеркаляции, что соответствует плотности заряда ~ 1014 см-2 для каждого слоя графена). Следовательно, обычная дисковая батарейка на 1000 мАч может активировать устройство размером с футболку (1 м2) около 180 раз. Кроме того, энергия потребляется исключительно во время цикла зарядки (интеркаляции). А средняя мощность в режиме ожидания практически равна нулю, что позволяет значительно продлить использования одного устройства без замены внешнего источника питания. Это, конечно, если не рассматривать идею с использованием человека в качестве источника энергии.

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

Эпилог


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

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

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

Благодарю за внимание, оставайтесь любопытствующими и хорошей всем рабочей недели, ребята. :)

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Мир без пчел роботизированное опыление мыльными пузырями

26.06.2020 10:22:09 | Автор: admin


Школьный курс биологии научил нас тому, что все живые организмы так или иначе связаны друг с другом. Посудите сами, на поле растет трава, зайцы едят траву, лисы едят зайцев. Но если одно из звеньев этой демонстрационной цепи исчезнет, то пострадают другие: исчезнут хищники зайцы начнут плодиться и съедят всю траву; исчезнет трава зайцам нечего будет есть, следовательно, лисы также будут голодать; исчезнут зайцы трава будет расти бесконтрольно, а лисы будут голодать. Пример достаточно утрирован, но суть доносит. Подобная ситуация касается и пчел, численность которых за последние годы катастрофически упала. Пчелы, как мы знаем, не только делают мед, но и выполняют одну из важнейших операций в природе опыление. Сегодня мы рассмотрим исследование, в котором ученые Си Ян и Эйдзиро Мияко описывают роботизированную систему опыления цветов посредством мыльных пузырей. Из чего состоит система, как именно она работает, и почему мыльные пузыри? Об этом мы узнаем из доклада ученых. Поехали.

Основа исследования


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

Около 3/4 видов культурных растений, которые человек выращивает для своих нужд, полагаются на пчел и других насекомых в вопросе опыления. Использование достаточно жестких методов борьбы с вредителями, расширение фермерских угодий и тотальная урбанизация привели к ощутимому снижению численности популяций этих организмов.

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

Более современный метод, машинный, позволяет опылять растения быстро и массово. Однако этот вариант очень затратный и менее эффективный, так как внушительная часть пыльцы попадает не туда, куда нужно (остается на самой машине, падает на землю или на листья и т.д.).

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


Дрон-опылитель

Относительно недавно был разработан дрон (Materially Engineered Artificial Pollinators), снабженный липким ионным гелем, покрытым животной шерстью.

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

И тут на помощь приходит научный эксперимент, который многие из нас неосознанно проводили еще в раннем детстве мыльные пузыри. Ученые отмечают, что пузыри много веков радуют детей и взрослых, являются частью выступлений многих артистов, но использование их в качестве функционального материала мало кого волнует.

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

В рассматриваемом нами сегодня исследовании показано, что химически функционализированные мыльные пузыри имеют уникальные свойства в аспекте опылений:

  • простая доставка пыльцевых зерен к целевым цветам;
  • сокращение использования пыльцевых зерен;
  • эффективное прикрепление мыльных пузырей к пестикам целевых цветов за счет высокой липкости мембраны мыльного пузыря;
  • предотвращение серьезного повреждения нежных цветов ввиду мягкости и высокой гибкости мыльных пузырей;
  • улучшение активности пыльцы за счет повышения степени прорастания и длины пыльцевой трубки.

Если объединить эти преимущества с автономностью робота, то можно получить практически идеальную систему опыления.

Раствор для мыльных пузырей



Изображение 1

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

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

В качестве опытного образца были использованы пыльцевые зерна Pyrus bretschneideri (китайская белая груша), а также мыльный пистолет с мотором и батареей, способный производить много пузырей за раз.

Во время опытов был измерен коэффициент прорастания и роста пыльцевых трубок груши.

Для начала было протестировано 5 вариантов поверхностно-активных веществ ( и ):

  • лаурамидопропил-бетаин (A-20AB);
  • лаурилсульфат натрия (E-27C);
  • лаурил-гидоксисульфо-бетаин (A-20HD);
  • сульфат полиоксиэтилен-алкилового эфира натрия (E-D3D);
  • [N-кокоил-(2-аминоэтил)-N-(2-гидроксиэтил)-N-натрийкарбоксиметил] этилендиамин (A- 20YB).

Эти поверхностно-активные вещества были случайным образом выбраны среди многих коммерчески доступных продуктов за их способность образовывать много мыльных пузырей при однократном запуске пузырькового пистолета.

Анализы активности пыльцы продемонстрировали, что все пять поверхностно-активных веществ показали дозозависимое ингибирующее действие на прорастание пыльцы и рост трубки. Коэффициент прорастания пыльцы (G) рассчитывали как G = N / Nt х 100 (%), где N и Nt обозначают количество наблюдений за пыльцевыми трубками с помощью оптической микроскопии и общее количество наблюдений (100 наблюдений). Кроме того, длина пыльцевых трубок измерялась по результатам прямого наблюдения и посредством программного обеспечения ImageJ.

Нейтрализованное поверхностно-активное вещество A-20AB продемонстрировало наивысшую эффективность с точки зрения прорастания пыльцы и роста трубок по сравнению с другими вариантами. Фактически, пыльцевые трубки в чашке Петри, обработанные мыльными пузырями с небольшой концентрацией A-20AB, росли абсолютно здоровыми (1D).

Стоит также отметить, что A-20AB обладал самой высокой способностью к образованию мыльного пузыря среди протестированных поверхностно-активных веществ.

Концентрации A-20AB и пыльцевых зерен оказали непосредственное влияние на образование мыльных пузырей (1E). Логично, что более высокая концентрация поверхностно-активного вещества может помочь создать много мыльных пузырей. А большое количество пыльцевых зерен может помешать образованию пузыря. Например, при концентрации A-20AB от 0.0% до 0.2% пузырьки не могут образовываться с пыльцевыми зернами 110 мг/мл, в то время как в случае от 0.4% до 0.8% и не более 4 мг/мл зерен можно получить как минимум более одного мыльного пузыря. Если же концентрация A-20AB будет 1.0%, а зерен будет 110 мг/мл, то будет образовываться 4-10 пузырей.

В итоге было решено использовать следующие параметры: концентрация A-20AB 0.4% и концентрация зерен 4 мг/мл. При перерасчете получается, что на каждый мыльный пузырь можно загрузить около 2000 пыльцевых зерен.

Чтобы повысить эффективность опыления, следовательно, и коэффициент прорастания, ученые также оптимизировали компоненты раствора мыльного пузыря. Одним из важных показателей, влияющих на рост пыльцевых трубок, является pH. Коэффициент прорастания достиг своего максимального значения (около 30.7%) при pH 7.0.

Более того, умеренное добавление бора, кальция, магния и калия стимулирует прорастание пыльцы и увеличение длины трубки. Особенно кальций, который улучшает прорастание благодаря связыванию кальция с пектатами карбоксильных групп вдоль стенки пыльцы. А остальные элементы (бор, калий, магний) усиливают этот эффект.

Добавление в мыльный раствор H3BO3 (060 мд; мд частей на миллион) привело к росту пыльцевой трубки до 1187 мкм, что в 1.3 раза больше, чем в контрольной группе (без H3BO3).

Подобная ситуация обстояла и с MgSO47H2O, который существенно не улучшал прорастание пыльцы, но стимулировал удлинение трубки при низкой концентрации (0.1 мМ), в пределах которой длина трубки достигала максимального значения 1127 мкм, что в 1.3 раза выше по сравнению с контрольной группой.

Также было обнаружено, что концентрация CaCl2 в диапазоне 0.12.0 мМ значительно улучшает коэффициент прорастания пыльцы и рост трубки (1152 мкм при 1.0 мМ CaCl2, что в 1.3 раза больше, чем в контрольной группе). KCl при концентрации 1 мМ сопутствовал удлинению трубки до 1232 мкм, что в 1.4 раза больше, чем в контрольной группе.

Желатин представляет собой водорастворимый белок, который состоит из большого количества глицина, пролина и гидроксипролина. Эти компоненты могут играть существенную роль в прорастании пыльцы и удлинении трубки. Добавление 0.8% желатина в раствор повышает коэффициент прорастания трубки до 50% (1363 мкм).

Для повышения стабильности мыльных пузырей был дополнительно использован небольшой процент гидроксипропилметилцеллюлозы (ГПМЦ). Добавление в раствор 0.2% ГПМЦ также слегка улучшило прорастание пыльцевых семян, но на рост трубки особого влияния не имело.

Толщина мыльного пузыря (его мыльной пленки) определяется по формуле:
= (M ) 4R2
где толщина мембраны; М масса (примерно 7.7 мг; плотность (примерно 0.99 г/см); R радиус (1.6 см).

Если аппроксимировать как 3.14, то будет равно 2.4 мкм, что является разумным значением для обычного мыльного пузыря в диапазоне толщин 110 мкм.

Ручное опыление с помощью мыльных пузырей


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


Изображение 2

В случае оптимизированного раствора коэффициент прорастания составил 49% (), а длина трубки составляла 1221 мкм (), что в 1.9 и 1.5 раза больше, чем в случае с неоптимизированным раствором (т.е. без каких-либо дополнительных веществ и элементов).

После 3 часов опыления показатели упали до 28% и 990 мкм. Однако даже они были в 5.9 и 1.9 раза выше, чем спустя 3 часа опыления неоптимизированным раствором. Следовательно, внедрение в раствор дополнительных элементов имеет значимое положительное влияние на рост семян.

Чтобы продемонстрировать возможности нового метода опыления, ученые провели наблюдения, где использовалось различное количество (0, 1, 2, 5, 10, 20 и 50) мыльных пузырей на цветках груши (2C). После инкубации в течение ночи при 25 С пестики цветов срезали и окрашивали анилиновым синим (специальный краситель, используемый в гистологии).

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

Логично и то, что количество пыльцевых зерен на каждом пестике увеличивалось с числом используемых пузырей. Однако, применение более 10 пузырей приводит к обратному эффекту, что может быть связано с токсичностью накопления раствора на цветке. Стоит отметить, что раствор не токсичен для цветков, токсично большое его количество (между лекарством и ядом разница в дозировке, как говорят).

Удивительно то, что спустя 16 дней после опыления мыльными пузырями сформировались молодые плоды, объем которых был сравним с объемом плодов после обычного ручного опыления перьевой кисточкой. Контрольная группа цветков, которым дали возможность быть опыляемыми природным путем (насекомыми) показала наименьшие результаты. В природных условиях необходимо полагаться исключительно на пчел и других опыляющих насекомых, которые не действуют по указке, т.е. не систематически (не говоря уже о том, что популяция пчел крайне сократилась).

В результате коэффициент образования плодов в контрольной группе составил всего 58%, а в тестовой (с мыльными пузырями) более 95%. Эти показатели говорят не только о том, что опыление посредством мыльных пузырей значительно эффективнее опыления вручную, но и том, что этот метод позволит увеличить объемы производства.

Роботизированное опыление с помощью мыльных пузырей


Опыление мыльными пузырями вручную хоть и эффективно, но не идеально, ибо ему не хватает автономности. Именно потому следующим этапом исследования стало испытание роботизированного варианта опыления пузырями.

Одной из первых проблем, с которыми можно столкнуться во время использования дронов, это воздушные потоки от винтов аппарата. Использованные в ручном опылении мыльные пузыри крайне быстро лопались, когда их пытались использовать в сопряжении с дронами. Следовательно, необходимо было повысить их стабильность. Для этого в раствор было добавлено 2% ГПМЦ. В результате были получены стабильные пузыри (2% ГПМЦ и 1% A-20AB) диаметром около 2 см ().


Изображение 3

Забавно, что эти пузыри не только выдерживали воздушные потоки от винтов дрона, но и достаточно долго (около 10 минут при 25 С) спокойно располагались на цветках без распада. Некоторые из пузырей оказались еще более выносливыми, так как могли прожить почти 5 часов и выдержать нагрузку сжатия до 0.03 Н. Толщина мембраны пузырей из теста на ручное опыление была 2.4 мкм, тогда как у стабилизированных толщина составила 4.1 мкм, что объясняется внедрением дополнительного ГПМЦ в раствор. При этом активность прорастания зерен сохранялась на достаточно высоком уровне.

Кинематическая вязкость приготовленного раствора мыльного пузыря составила 7530 сСт*, а плотность 1.023 г/см.
сСт* (сантистокс): 1 сСт = см/с.
Относительно высокая вязкость раствора имела положительный эффект на дисперсию пыльцы, что было доказано проведением оптической микроскопии.

Ученые также подсчитали количество пыльцевых зерен разных растений на каждом пузыре: 269 частиц L. japonicum; 304 частицы R. pulchrum; 312 частиц C. persicifolia).

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

Коэффициент успешного опыления отличался у разных цветков. Так у L. japonicum () он составил 90%, потому что цветки этого растения больше, чем у других протестированных.

В сопряжении с дроном также был использован автоматический пузырьковый пистолет (3D), который генерировал 5000 пузырьков в минуту. На роль дрона-носителя был использован самый обычный и коммерчески доступный беспилотник, к которому прикреплялся пузырьковый пистолет.

Движения дрона контролировались автоматической системой, оснащенной глобальной навигационной спутниковой системой (GNSS). При подлете к цветкам на расстояние в 2 м производился пузырьковый обстрел под углом 70-80 градусов. Скорость воздушных потоков от дрона составляла 4.5 м/с, когда он стабильно зависал в воздухе. При движении (2 или 4 м/с) она увеличивалась до 5.8 и 8.7 м/с. Из-за этого мыльные пузыри моментально лопались при контакте с цветками. Анализ последующих показателей прорастания показал, что оптимальной скоростью движения дрона является 2 м/с. В таком случае коэффициент прорастания будет порядка 90%.

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

Эпилог


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

Роботы же подчиняются правилам, установленными человеком (пока что). Но не роботы важны в этом исследовании, а обычные мыльные пузыри. Структурно эта хрупкая система редко применяется в качестве материальной базы для чего-либо. Ученые считают, что это большое упущение, поскольку мыльные пузыри весьма полезны.

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

Конечно, эта разработка уникальна и очень полезна. Тем не менее, не стоит считать, что имея подобные технологии в своем распоряжении, можно наплевательски относиться к тем, кто опылением занимался задолго до того, как появились дроны, алгоритмы и прочие примочки. Природа окружает нас всегда, даже если мы живем в городах, наполненных металлом, бетоном и стеклом. От любого, даже самого маленького существа (конечно, если это не паразит), так или иначе есть польза экосистеме, в которой он живет. Остается лишь один вопрос какова польза от нас? Ответ на него у каждого свой, кто-то прав, а кто-то нет. Философствовать можно часами, но вывод простой, как инфузория туфелька, может мы и самые умные существа на планете, но это не дает нам права эту планету подминать под себя.

Пятничный офф-топ:

Разные виды пчел защищают свой дом от врагов разными методами. Гигантские пчелы (Apis dorsata) формируют волну, словно болельщики на стадионе.

Благодарю за внимание, оставайтесь любопытствующими и отличных всем выходных, ребята! :)

Немного рекламы


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Чешуйчатый Икар кинематика полета древесной змеи

03.07.2020 10:08:54 | Автор: admin


Рожденный ползать летать не может. Эту фразу можно применять как в метафорическом смысле, так и в буквальном, ибо существа без крыльев (или подобных по функционалу частей тела) действительно не способны покорять небеса. По крайней мере, большинство из них. Правило не было бы правилом, если бы не было исключений. В аспекте бескрылых полетов исключения также имеются украшенные древесные змеи (Chrysopelea). Представители этого рода змей способны парить крайне полезный навык учитывая, что живут они в кронах деревьев высоко над землей. Ученые из Политехнического университета Виргинии (США) решили рассмотреть полет змеи с точки зрения кинематики. Какие анатомические особенности позволяют змеям летать (контролировано падать, если точнее), что происходит во время полета с точки зрения кинематики, и как данное исследование может помочь в робототехнике? Ответы на эти вопросы ждут нас в докладе ученых. Поехали.

Основа исследования


Украшенные древесные змеи это род змей из семейства ужеобразных, обитающие в Южной и Юго-Восточной Азии. Представители этого рода не могут похвастаться большими габаритами (длина тела всего лишь от 0.6 до 1.5 м) и смертоносным ядом. Хотя добыча, на которую они охотятся в дневное время, не согласилась бы с последним. Учитывая место обитания (кроны деревьев), у данных змей крайне мало врагов, потому особой нужды в сильном яде у них нет. К тому же у них есть куда более эффектная тактика они умеют планировать.



Летающие змеи, как их еще называют в народе, ползают по деревьям, используя жесткие чешуйки вдоль живота, позволяющие им двигаться вертикально. Если змея желает перебраться с одного дерева на другое, она в первую очередь подползает к краю ветки, затем складывает тело в форму латинской буквы J, чтобы прицелиться (определить желаемый угол взлета и место посадки). Сказав поехали, змея толкает свое тело вперед и вверх, втягивая живот и выпячивая ребра (так ее тело становится более плоским и слегка вогнутым). Во время планирования змея постоянно совершает серпантиновидные движения телом из стороны в сторону, что позволяет ей контролировать полет и мягко приземлиться.


Вид сбоку на длинное планирование летающей змеи Chrysopelea paradisi.

Дополнительным плюсом столь необычного для змей метода передвижения является внушительная экономия энергии, ведь перелет гораздо быстрее (и безопаснее) медленного переползания с дерева на дерево по земле. Из одно лишь этого короткого описания понятно, что в механике полета змеи имеется множество важных элементов; угол взлета, форма тела во время взлета и полета, движения телом в полете и т.д.

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

У змей Chrysopelea волнистость характеризуется S-образной формой тела, низкой частотой волнистости (12 Гц) и уплощенным аэродинамическим поперечным сечением тела.


Изображение 1

По сути воздушная волнистость непрерывно перестраивает тело змеи, превращая его по форме в крыло (). Ранее проведенные исследования показали, что летающие змеи всегда исполняют волнистые движения в полете. Однако остается неясным, является ли волнистость основной частью успешного полета или это просто привычка, т.е. поведенческий аспект перемещения по суше, перекочевавший в полет без каких-либо намерений.

Если учитывать волнистость на суше и воде, то можно предположить, что и в воздухе она генерирует тягу. На твердых средах волнообразное движение происходит благодаря распределенным контактным силам над вентральными и латеральными областями тела, а в воде смещение или всасывание жидкости вдоль тела вызывает движение вперед. В обоих случаях чистая движущая сила действует преимущественно в плоскости волнистости. Модуляция тела вне плоскости (в вертикальном направлении) может использоваться для вторичных целей, таких как уменьшение сопротивления или увеличение нормальной силы.

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


Вид спереди на взлет и уплощение летающей змеи Chrysopelea paradisi.

Результирующие аэродинамические силы должны действовать вне плоскости волнистости, а сама волнистость должна постоянно менять распределение сил на тело змеи. Стоит также учесть, что летающие змеи могут волноваться не только горизонтально, но вертикально. Значит, что в модели полета змеи присутствуют как элементы тангажа*, так и элементы крена*.
Тангаж* угловое движение относительно горизонтальной поперечной оси инерции.

Крен* угловое движение относительно его продольной оси.
В данном исследовании ученые решили детально рассмотреть роль волнистости в полете змеи. Используя записи высокоскоростной съемки полета змеи, ученые смогли количественно измерить воздушную волнистость. Полученные данные позволили создать точную трехмерную модель полета змеи.

Результаты исследования


Воздушная волнистость состоит из связки волн горизонтального и вертикального изгиба. Вдоль тела змей (7 особей), участвовавших в съемке полета (высока взлетной площадки 8.3 м), были размещены 11-17 маркеров. Оценка изменения положения этих маркеров позволяет точно определить структуру волнистости во время полета.


Вид сверху на тестовое планирование летающей змеи Chrysopelea paradisi.


Инфракрасные маркеры, полученные во время планирования летающей змеи Chrysopelea paradisi.

Проведя 36 практических наблюдений, ученые создали трехмерную модель тела змеи ( r ).


Разработка 3D-модели летающей змеи Chrysopelea paradisi по данным захвата движения.

Используя касательный вектор (t = r/s), удалось разложить волнистость на две угловые волны изгиба, которые движутся вдоль тела.

Горизонтальные и вертикальные волны задаются следующими формулами:

(s, t) = -tan-1 t x / t y

и

(s, t) = sin-1 t z

где (s, t) и (s, t) локальные углы, которые тело образует относительно горизонтального и вертикального направлений, как функции длины дуги s и времени t.

Данные показывают, что летающие змеи используют две волны: горизонтальную волну с большой амплитудой и вертикальную волну с меньшей амплитудой, обе из которых последовательно проходят вниз по телу от головы к хвосту (изображение 2).


Изображение 2

Эти волны формируются после начального переходного процесса, когда змея прыгает в относительно прямой позе и затем формирует характерную S-образную позу для планирования.

Существует четыре особенности воздушной волнистости, связывающей вертикальную волну с горизонтальной (). Во-первых, вертикальная волна имеет пространственные и временные частоты, в два раза превышающие частоты горизонтальной волны. Это указывает на то, что у тела в два раза больше вертикальных изгибов, чем боковых (, ). Во-вторых, U-изгибы на теле летающей змеи можно идентифицировать как нулевое пересечение на графике угла изгиба (2b). В-третьих, эти пересечения являются максимумами вертикальной волны, указывая на то, что горизонтальные и вертикальные волны сдвинуты по фазе на 90. В-четвертых, максимальный изгиб вне плоскости происходит на U-изгибах и примерно на середине прямых сегментов. На U-изгибах поперечное сечение крыла змеи сворачивается из-за движения тела вне плоскости (1c, 1d).

Форма бегущих волн изменяется со временем, поскольку змея ускоряется и производит аэродинамические силы, однако некоторые особенности все же остаются общими. Горизонтальная волна представляет собой синусоиду с плоским верхом, амплитуда которой (80-120) зависит от количества пространственных периодов, причем меньшее количество периодов приводит к более высоким горизонтальным углам изгиба. Вертикальная волна представляет собой узкопиковую синусоиду с широкими впадинами с амплитудами в диапазоне от 20 до 45.

Количественная оценка пространственных и временных характеристик волн показала, что змеи используют горизонтальные волны с 11.5 пространственными периодами и частотой волнистости 1-1.7 Гц и вертикальные волны с 23 пространственными периодами и частотой волнистости 23.4 Гц.

В воздушной волнистости есть дополнительный компонент, который ученые назвали дорсо-вентральным изгибом, представляющий движение вверх и вниз задней части тела относительно головы. Угол наклона этого изгиба составил от -20 до 30. Дорсо-вентральной изгиб всегда присутствовал в наблюдаемых полетах, но не имел значимой связи с количеством пространственных периодов.

Чтобы точно определить степень влияния связи горизонтальных и вертикальных волн, а также влияние дорсо-вентрального изгиба на динамику полета, ученые создали анатомически точную модель змеи в полете. Контроль над моделью позволяет, по словам ученых, систематически проверять, как компоненты волнистости (амплитуда горизонтальной волны, количество пространственных периодов и частота волнистости) влияют на краткосрочную и долгосрочную динамику планирования.

Горизонтальная волна моделируется как синусоида с плоской вершиной большой амплитуды, а вертикальная волна как синусоида небольшой амплитуды:



где m and m максимальные горизонтальные и вертикальные углы изгиба; число пространственных периодов; f частота волнистости; фазовый сдвиг; d дорсовентральный угол изгиба; L длина тела (2f, 2g).

Горизонтальные и вертикальные волны связаны в кинематических данных (): = 2, f = 2f и = 2( /2). Это сильно упрощает модель до 5 переменных, определяющих форму тела: m, m, , f и d.

Положение r = [x, y, z] тела относительно центра масс рассчитывается следующим образом: sx = cossin, sy = -coscos и sz = sin.

Положение центра масс R0 и ориентация тела (углы рыскания*, тангажа и крена) определяются путем интегрирования уравнений поступательных и вращательных движения.
Рыскание* угловые движения относительно вертикальной оси.


где fL и fD бесконечно малые силы подъема и сопротивления; MA аэродинамический момент; m масса змеи.

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


Изображение 3

Судя по сравнению, модель работает, однако имеет некоторые незначительные неточности, которые требуют устранения в будущем.

Для проверки влияния волнистости на характеристики планирования было проведено два моделирования: с f = 0 Гц (без волнистости) и f = 1.2 Гц (средняя частота волнистости у змей). В обоих вариантах варьировались и m ().


Изображение 4

Кинематические данные формы тела змеи в модели позволили получить 121 форму с 1 1.5 объемными волнами и амплитудами горизонтальных волн в диапазоне 90 m 119. Далее из этого массива были выделены наблюдаемые формы тела (средняя часть графика, отделенная по диагонали; 4b). Часть графика, что ниже выделенной, содержит открытые (напоминающие букву S) формы тела, а верхняя закрытые (напоминающие знак бесконечности).

Амплитуда вертикальной волны и дорсовентральный угол поддерживались на постоянном уровне: 20 и 10 соответственно. Моделирование считалось завершенным, когда центр массы тела змеи касался земли (приземление) или когда любой из углов ориентации превышал пороговое значения в 85. Если это происходило, то планирование считалось нестабильным, т.е. не таким, как в природе. В процессе моделирования были протестированы как краткосрочная динамика (высота старта 10 м), так и длительную динамику (высота старта 75 м) с/без волнистости.

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


Моделирование летящей змеи, планирующей с волнистостью и без нее.

Короткие планирования с высотой запуска 10 м показали хороший коэффициент стабильности при наличии волнистости (94%). Если же волнистость не была включена в модель, то стабильными были лишь 50% полетов. Волнистость также увеличивает расстояние планирования (с 4 м до 4.3 м).

При моделировании планирования с высоты 75 м волнистость увеличила как горизонтальное, так и вертикальное расстояние до того, как проявляется нестабильность в 86% запусков. В данном случае волнистость также увеличивала расстояние полета в 92% запусках. Волнистость также увеличила среднее расстояние по горизонтали на 6.9 м.

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


Изображение 5

Было смоделировано планирование с m = 0, 10 и 20 и дорсовентральным изгибом от -20 до 20 с шагом в 10 () для 11 различных форм тела.

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

Совершенно плоская змея (m = 0), чего никогда не наблюдалось во время экспериментальных испытаний, показала ожидаемо наихудшие результаты. Увеличение амплитуды вертикальной волны повышало эффективность планирования из-за скручивания поперечного сечения в плоскости, обеспечивающего более выгодный угол для создания силы (2j).

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

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

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

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

При увеличении дорсовентрального изгиба от -20 до 10 позиция посадки моделируемой змеи увеличивается по мере того, как средний шаг тангажа увеличивается в направлении нуля (5d). При дорсовентральном изгибе 20 усредненный по фазе момент тангажа становится положительным, и характеристики планирования снижаются.

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

Метки усредненных по фазе моментов тангажа на 5e соответствуют наклону вверх или наклону, показанному на 5c, и результирующим характеристикам планирования на 5b. На 5f показан, что для форм тела с наименьшим пространственным периодом средний момент тангажа будет наименьшим.

Из вышеописанных данных можно предположить, что вертикальная волна заставляет тело сворачиваться вне плоскости, изменяя локальную ориентацию сплющенного крыла (форма тела змеи во время планирования) с помощью потока воздуха. Дорсовентральный изгиб контролирует величину и знак аэродинамического основного момента, который воздействует на тело. Летающая змея может контролировать момент тангажа, изменяя во время полета угол изгиба дорсовентрального отдела или форму горизонтальной волны.

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


Изображение 6

Анализ фазы путем усреднения позволяет количественно оценить относительный вклад аэродинамических и инерционных моментов в динамику планирования.

Из уравнений 5 следует, что на ориентацию тела влияют как аэродинамические силы, так и изменяющееся распределение массы. Аэродинамический вклад () увеличивается со временем по мере увеличения скорости, тогда как инерционный вклад (6b) остается постоянным. Оба момента являются периодическими, и только момент тангажа показывает ненулевое среднее значение по фазе.

Около осей тангажа и крена первоначально преобладают инерционные моменты, но в течение одного волнообразного цикла их вклад быстро уменьшается. Инерционные моменты рыскания, как правило, на порядок больше аэродинамических моментов рыскания и больше, чем инерционные моменты вокруг других осей. Инерционные моменты рыскания возникают из-за горизонтальной волны большой амплитуды и широкой S-образной формы тела. Этот результат говорит о том, что летающие змеи могут использовать инерционное вращение в качестве механизма маневрирования.

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

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

Эпилог


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

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

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

Авторы сего труда считают, что их данные не только позволили нам лучше понять повадки украшенных древесных змей, но и получить дополнительное вдохновение для создания змееподобных роботов. Да, такие роботы уже есть. Они ползают, могут перемещаться по сложным поверхностям и проникать в труднодоступные места, но могут ли они летать?

С такими рассуждениями наш мир скоро будет похож на город машин из Матрицы, где по стенам ползали крайне необычные (и слегка пугающие) роботизированные существа, назначение которых было сложно понять. Желание человека сделать робо-версию всего, что его окружает, нельзя журить. Такова наша природа все понять, все знать, уметь создавать то, что до нас прекрасно делала природа. Если от роботизированных змей, пауков, собак и других робо-зверей будет намного больше пользы, чем вреда такие исследования полностью оправданы.

Благодарю за внимание, оставайтесь любопытствующими и отличных всем выходных, ребята! :)

Пятничный офф-топ:

Дэвид Аттенборо рассказывает о том, как двигаются некоторые виды змей.

Офф-топ 2.0:

Это одна из самых эпичных сцен погони, которые я когда либо видел :)
Подробнее..

От Литвы до Нью-Йорка разведывательному делу КГБ посвящается

16.06.2020 18:07:02 | Автор: admin
Совсем недавно о применявшейся КГБ шпионской технике можно было разве что прочесть в книгах или подсмотреть в фильмах о Джеймс Бонде. Устаревшее оборудование строго уничтожалось по всем правилам с подписанием чреды специальных актов, хотя часть технологий и передавалась для использования в военную промышленность, для обычного гражданина СССР была недоступна.



Каунас, Литва 2014 год. Ядерный бункер стал убежищем для уникального шпионского музея. На глубине 6 метров под землей находится частная коллекция необычных экспонатов. Интерес представляет экспозиция Шпионский Музей КГБ. Это коллекция устройств и приборов для тайной слежки, которые использовали НКВД, КГБ и другие спецслужбы. Бункер КГБ заполнен техникой для тайного взлома и обыска: телефоны, переносные секретные средства радиосвязи, радиопередатчики и приемники, блокаторы связи, пеленгаторы, жучки и всевозможные шпионские штуки. Кураторы музея семья Урбайтис: отец и дочь. Глава семейства посвятил делу более 30 лет своей жизни, благодаря его необычному хобби появилась возможность увидеть, пощупать секретное спецоборудование КГБ.


Юлиус Урбайтис и Агне Урбайтис

Выставки


Устройства для маскировки


Скрытые камеры и оборудование для прослушки (жучки) использовались для записи разговоров во время секретных операций. Сделанные таким образом фотографии людей, мест, документов потом могли быть использованы с целью шантажа. Операции по сбору компрометирующих материалов требовали не только высокой подготовки специалистов (шпионов), но и применения дорогостоящего оборудования. Устройства прослушки могли быть размещены где угодно: в доме, в машине, в парке, в ванной, даже в чипе на ухе вашего любимого питомца. Все это позволяло КГБ записывать и отслеживать информацию, которая могла быть использована в любых выгодных спецслужбах назначениях.









Фотокамеры


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



Представлен здесь и субминиатюрный фотоаппарат ТОЧКА-58. Был разработан в 1958 году на основе американского фотоаппарата MINOX. Уникальный прототип, где были использованы те же принципы схема подачи пленки, дизайн кассет и другие детали аппарата. Предназначение механической сверхминиатюрной ТОЧКИ (габариты-83х30х15 мм) не что иное, как чистой воды шпионаж. Технические характеристики такой камеры: размер негатива 8,5 х 11 мм, используемая пленка 9,5 мм в кассетах типа Minox, скорость затвора 1/10, 1/50, 1/150 и 1/400 сек, перемотка пленки 27 кадров последовательно при помощи пружинного двигателя и взвода затвора.




ТОЧКА-58


MINOX

Записывающие устройства


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



Среди экспонатов музея самое миниатюрное записывающее устройство времен холодной войны Мi-51. Чудо техники с габаритами всего 17 x 11 x 3,5 см, легко помещалось в кармане или сумочке. Работал такой гаджет на батарейках и мог производить запись в течении двух часов. Камера Мi-51 использовалась и спецслужбами Соединенных Штатов.


Наручные часы-микрофон, оснащенный Мi-51. Микрофон подключался к диктофону при помощи провода.



Еще одно уникальное оборудование, представленное в музее шпионский диктофон Yachta / Яхта / Явiр-1. Двухканальный диктофон, копия легендарного швейцарского диктофона Nagra SNST был разработан в 1987 году (Киев, Украина). Внешне отличался от швейцарского оригинала только отсутствием стрелочного индикатора питания/уровня сигнала.

Технические характеристики диктофона Яхта-1М / Явiр-1:

  • Габариты 156 х 103 х 27 мм
  • Вес 600 грамм (без батареек и катушек)
  • Скорость движения ленты стабилизированная 2,38 см/сек
  • Ширина ленты 3,81 мм
  • Питание 2-3 в, две батарейки типа АА, по паспорту элементы А-316 Прима, или аккумуляторов ЦНК-0,45
  • Полоса частот 170 6000 Гц
  • Коэффициент детонации не более 0,35 %
  • Коэффициент гармонических искажения не более 3 %



Шифровальные машины


Отдельного внимания заслуживает выставка шифровальных машин времен холодной войны. Самым изощренным экспонатом является советская внучка легендарной Enigma криптомашина Фиалка М-125. Электромеханическая 10 роторная шифровальная машина была разработана в 1956 году, вскоре стала самой популярной в странах Варшавского договора. После падение Берлинской стены в 1989 году и распада Советского Союза уцелевшие машины Фиалки были демонтированы или уничтожены. Тем не менее, музею удалось заполучить один экземпляр и сохранить его. Посетители могут насладиться этим шедевром советской разработки.



Шпионские радиостанции


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

РИОН, СЕЖА А610, Р-350 ОРЁЛ почетные экспонаты выставки.


Рион

Коротковолновая приемо-передающая переносная телеграфная радиостанция ''РИОН'' предназначалась для симплексной и полудуплексной двусторонней связи, использовалась в секретных операциях, работала в диапазоне частот от 2,5 до 10 МГц (передатчик) и от 2 до 12 МГц (приемник ПР-56). Станция весом в 37 килограмм со всеми комплектующими размещалась в двух чемоданах, устройство можно было запитывать и в полевых условиях от аккумулятора 12 вольт с емкостью не менее 45 ампер-часов.


Р-350 ОРЁЛ

Р-350 первая советская шпионская радиостанция, запущенная в массовое производство. Чрезвычайно удобная в обслуживании, надежная станция использовалась спецназом, ГРУ, подвижными разведгруппами парашютного десанта МГБ. Устройство состояло из передатчика, приемника и источника питания. Р-350 была усовершенствована и стала выпускаться как Р-350М. Диапазон частот передатчика составлял от 1800 до 1200 кГц (167-25 м), а выходная мощность не менее 6 Вт. Диапазон частот приемника составлял от 1800 до 7000 кГц (167-42,9 м).

Спецтелефоны


Вертушка телефон закрытой системы спецсвязи для органов партийной и государственной власти СССР. Отдельно аппараты-вертушки не годились для секретных переговоров, лишь только в связке с другими системами защищенной правительственной связи могли служить общей цели. АТС-1 (полагалась высшему эшелону власти), АТС-2 (полагалась уровню а-ля заместителя министра) телефонные дисковые аппараты цвета слоновой кости с гербами.



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



Интерес к шпионскому оборудованию времен СССР однозначно высок. Свидетельством данного факта служит открытие под кураторством семьи Урбайтис еще одного уникального музея в США в прошлом году (владельцы оставили за собой право остаться в тени). 3500 экспонатов на West 14th Street в Манхеттене молчаливые свидетели советского дела разведки.



Но этот музей, согласно словам г-жи Урбайтис, является аполитичным. Он представляет историческую ценность, посвящен техническому прогрессу. Ее отец, 55-летним Юлиус Урбайтис посвятил сбору коллекции 3 десятилетия. Сначала его интересовали артефакты времен Второй мировой войны, позже он приобрел устройство для прослушки, принадлежащее Адольфу Гитлеру, так и начался его путь увлечения шпионажем. Некоторые экспонаты из Ядерного Бункера мигрировали в новый музей.







Радиопередатчики, шифровальные машины, миниатюрные фотоаппараты это только малость из представленных объектов выставки. Наряду с техникой реконструкция рабочих мест агентов КГБ, коллекция тяжелых стальных наручников, кресло для допросов с кожаными ремнями и зонт с отравленной иглой, которым в 1978 году был убит болгарский диссидент Георгий Марков.











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

Почему Литва и США? Хранение такой спецтехники в России, к примеру, является уголовным преступлением и наказывается лишением свободы сроком до 6 лет. Эта техника в России до сих пор не рассекречена, поэтому там нет и в ближайшее время не может быть таких музеев.

Немного рекламы :)


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Как IT гиганты помогают образованию? Часть 1 Google

29.06.2020 16:21:22 | Автор: admin
На старости лет, в свои 33 года, решил я пойти в магистратуру по компьютерным наукам. Первую свою вышку я закончил ещё в 2008 и совсем не в сфере ИТ, много воды с тех пор утекло. Как и любому другому студенту, ещё и со славянскими корнями, мне стало любопытно: что я могу получить на халяву (в основном в плане дополнительных знаний по специальности)? И, коль скоро моё прошлое и настоящее плотно пересекается с хостинг-индустрией, основной выбор пал на гигантов, предоставляющих облачные услуги.

В своём небольшом цикле я расскажу о том, какие образовательные возможности предлагают три лидера рынка облачных услуг студентам, преподавателям и учебным заведениям (как университетам, так и школам), а также как использует некоторые из них наш ВУЗ. И начну я с Google.



Сразу за хабракатом немного разочарую. Жителям стран СНГ не очень повезло. Часть вкусных плюшек Google For Education там не доступна. Потому о них я расскажу в конце, специально для тех, кто учится в вузах Европы, Северной Америки и некоторых других стран. Часть из них доступна в урезанном виде, впрочем. Итак, поехали.

G Suite for Education


Многие из нас любят Gmail, Google Drive и ежи с ними. Особо везучие даже успели захватить бесплатные аккаунты почты для своих доменов, ныне известную как G Suite legacy free edition, которой постепенно закручивают гайки. Если кто не знает, G Suite for Education это всё то же, и даже больше.

Любая школа и любой ВУЗ может получить 10000 лицензий (и, соответственно, аккаунтов) на почту, диск, календарь и прочие возможности сотрудничества, предлагаемые G Suite. Единственное ограничение учебное заведение должно иметь государственную аккредитацию и статус некоммерческой.

Наш университет активно пользуется этим сервисом. Долой хождение к деканату, чтобы узнать, какая пара следующая. Всё синхронизируется через календарь и можно посмотреть в смартфоне. Равно как и расписание экзаменов. Важные уведомления и указы рассылаются всем по мылу, равно как и уведомления о различных интересных семинарах, вакансиях для студентов, летних школах и т.п. Для каждой логической единицы (группа, курс, факультет, вуз) создан список рассылки, и сотрудники с соответствующими правами могут туда отправлять информацию. На вводной лекции для студентов прямым текстом сказали, что университетский ящик проверять очень важно, практически обязательно.

Кроме того, некоторые преподаватели активно заливают материалы лекций на Google Drive и даже создают там же индивидуальные папки для отправки домашки. Другим, впрочем, вполне подходит Moodle, не имеющий отношения к Google. Подробнее о создании аккаунта можно почитать тут. Срок рассмотрения заявки составляет до 2 недель, но по случаю массового удалённого обучения Google обещал рассматривать и подтверждать их быстрее.

Google Colab


Отличный инструмент для любителей Jupyter Notebook. Доступен любому пользователю Google. Очень удобен как для индивидуальной, так и для совместной работы при изучении чего-либо из сферы машинного обучения и data science. Позволяет тренировать модели как на CPU, так и на GPU. Впрочем, для базового изучения Python тоже вполне подойдёт. Мы активно использовали этот инструмент на Методах интерпретации и классификации. Начать коллаборацию можно тут.


Контуры (для искушённых один из слоёв нейронки VGG16) египетского котика делают коллаборацию лучше

Google Classroom


Отличная LMS (learning management system), предоставляемая бесплатно как один из основных продуктов в рамках пакетов G Suite for Education, G Suite for Nonprofit, а также владельцам персональных аккаунтов. Также предоставляется как дополнительная услуга для обычных аккаунтов G Suite. Система перекрёстных разрешений доступа между разными типами аккаунтов несколько запутанная и нетривиальная. Чтобы не залазить в дебри, самый простой вариант всем участникам процессам учителям и ученикам пользоваться аккаунтами одного типа (либо образовательные, либо персональные).

Система позволяет создавать классы, публиковать текстовые и видеоматериалы, сессии Google Meet (бесплатны для образовательных аккаунтов), задания, оценивать их, общаться между собой и т.п. Очень полезная штука для тех, кто вынужден обучаться удалённо, но у кого нет в штате специалистов, чтобы установить и настроить какую-то другую LMS. Переступить порог класса можно тут.

Обучающие материалы


Google подготовил несколько различных возможностей научиться работать с их облачными услугами:
  • Подборка курсов на Coursera доступна для прослушивания бесплатно. Студентам из стран, которым особо повезло, предоставляется также возможность бесплатно выполнять практические задания (обычно платная услуга) и получить сертификаты по 13 курсам от Google. Впрочем, Coursera предоставляет по запросу финансовую помощь на свои курсы (т.е. просто предоставляет их бесплатно, если сможете их убедить, что Вам это очень надо, но денег нет но Вы держитесь). Некоторые курсы доступны полностью бесплатно до 31.07.2020.
  • Ещё одна подборка на Udacity
  • Вебинары Cloud OnAir рассказывают о возможностях и об интересных кейсах, созданных на базе Google Cloud.
  • Google Dev Pathways подборки статей и упражнений, раскрывающий различные темы, касающиеся работы с Google Cloud. Доступны для бесплатно для всех пользователей Google.
  • Codelabs подборка руководств по совершенно различным аспектам работы с продуктами Google. Пути (Pathways) из прошлого пункта являются упорядоченными подборками лабораторок отсюда.

Google for Education


Определённая подборка возможностей по изучению работы с услугами Google доступна лишь для ограниченного круга стран. Грубо говоря, страны ЕС/ЕЭЗ, США, Канада, Австралия, Новая Зеландия. Я учусь в Латвии, так что погреть руки об эти возможности получилось. Если Вы также учитесь в одной из упомянутых стран, наслаждайтесь.
  • Возможности для студентов:
    • 200 кредитов на прохождение интерактивных лабороторок на Qwiklabs.
    • Бесплатный доступ к платным версиям 13 курсов от Coursera (уже упоминал выше).
    • $50 кредитов Google Cloud (на момент написания статьи временно не предоставляется; однако всё равно можно получить тестовые $300, предлагаемые по дефолту при активации пробной подписки).
    • Скидка 50% на сертификацию G Suite.
    • Скидка 50% на экзамен Associate Cloud engineer (зарегистрироваться в программе должен представитель факультета).
  • Возможности для факультетов:
    • 5000 кредитов Qwiklabs, которыми можно поделиться со студентами.
    • $300 кредитов Google Cloud на проведение курсов и различных мероприятий.
    • $5000 кредитов Google Cloud на проведение исследовательских программ (на каждую программу).
    • Программа готовности к карьере бесплатные обучающие материалы и скидка на сертификацию Associate Cloud engineer для студентов и преподавателей.
  • Возможности для исследователей:
    • Соискатели докторской степени (PhD) могут получить $1000 кредитов Google Cloud для своих исследований.

В официальной информации сказано, что Google работает над расширением географии, но есть предположение, что в скором времени ожидать его не стоит.

Вместо заключения


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

От себя хотим также предложить всем студентам скидку 50% на первый год использования наших услуг хостинга и облачных VPS, а также VPS с выделенными накопителями. Для этого Вам необходимо зарегистрироваться у нас, сделать заказ и, не оплачивая его, написать тикет в отдел продаж, предоставив фото себя со своим студенческим. Сотрудник отдела продаж скорректирует Вам стоимость заказа в соответствии с условиями акции.

И всё, другой рекламы не будет.
Подробнее..

Перевод Будущее дата-центров

01.07.2020 00:06:33 | Автор: admin
Учитывая, что к 2025 году ожидается 175 зеттабайт данных, дата-центры будут продолжать играть чрезвычайно важную роль в приеме, исчислении, хранении и управлении информации.


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

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

image

Местоположение


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

По некоторым оценкам, мировой рынок строительства ЦОД к 2025 г. может составить до $57млрд. Это достаточно большой вызов, так, как гигант коммерческой недвижимости CBRE запустил целое подразделение, специализирующееся именно на дата-центрах

Карта центров обработки данных
image



Строительство рядом с дешевыми источниками энергии



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

Apple и Facebook построили дата-центры рядом с гидроэнергетическими ресурсами. В центре штата Орегон компания Apple приобрела гидроэнергетический проект для обеспечения своего центра обработки данных в Принвилле зеленой электроэнергией. Компания уточнила, что дерегулированные рынки электроэнергии штата Орегона являются основной причиной почему они построили несколько центров обработки данных в этом районе. Дерегулирование позволяет Apple покупать электроэнергию непосредственно у сторонних поставщиков, которые используют возобновляемые источники энергии, а не только у местных коммунальных служб.

В Лулео, Швеция, Facebook построил мегацентр данных рядом с гидроэлектростанцией. В Швеции, дата-центры начали появляться в северном регионе, так как, помимо того, что климат прохладный, и локация не подвержена землетрясениям, в этой части очень много возобновляемых источников энергии(гидроэнергия и ветер).

image

Строительство Facebook в Лулеа, Швеция, в 2012 году. Источник: Facebook

Несколько крупных центров обработки данных уже переехали в Северный регион, некоторые только присматриваются к нему.
В декабре 2018 года Amazon Web Services объявила об открытии своего дата-центра AWS Europe Region, расположенного примерно в часе езды от Стокгольма. В том же месяце Microsoft приобрела 130 гектаров земли в двух соседних частях Швеции, в Евле и Сандвикене, с целью строительства там центров обработки данных.

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

Телекоммуникационная компания Altice Portugal заявляет, что ее дата-центр Covilh использует наружный воздух для охлаждения своих серверов на 99%. А старый центр обработки данных Google в Хамина, Финляндия, использует морскую воду из Финского залива для охлаждения объекта и снижения энергопотребления.

Компания Verne Global открыла в Исландии кампус, который подключается к местным геотермальным и гидроэнергетическим источникам. Он расположен на территории бывшей базы НАТО и находится между Европой и Северной Америкой двумя крупнейшими рынками данных в мире.

Строительство в странах с развивающейся экономикой



Размещение центра обработки данных в точке растущего интернет-трафика снижает нагрузку и увеличивает скорость передачии данныхв в регионе.

Например, в 2018 году китайская компания Tencent, которой принадлежат Fortnite и WeChat, разместила центры обработки данных в Мумбаи. Этот шаг стал признаком того, что в регионе активно используется интернет и игровые платформы Tencent становятся все более популярными.

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

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

Налоговые льготы и местное законодательство



Информационные центры являются важным новым источником доходов для производителей электроэнергии и поэтому государство привлекает крупные компании разными льготами.

Начиная с января 2017 года, шведское правительство снизило налог на 97% на любую электроэнергию, используемую центрами обработки данных. Электроэнергия в Швеции относительно дорогая, и снижение налогов поставило Швецию в один ряд с другими скандинавскими странами.

В декабре 2018 года компания Google договорилась об освобождении от уплаты налога на продажу центра обработки данных в Новом Олбани, штат Огайо, на 100% 15-летний срок для центра обработки данных стоимостью 600 млн долл. Льгота было предложена с возможностью продления до 2058 года. В сентябре 2018 года Франция, после Брексита надеясь привлечь экономические таланты и мировой капитал, объявила о своих планах по снижению налогов на потребление электроэнергии для дата-центров.

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

В феврале 2018 года компания Apple начала хранить данные в центре, расположенном в Гуйчжоу, Китай, чтобы соответствовать местным законам. Если раньше для получения доступа к информации граждан Китая, хранящейся в американском центре обработки данных, китайским властям приходилось пользоваться правовой системой США, то теперь местный центр обработки данных предоставляет властям Китая более простой и быстрый доступ к информации граждан Китая, хранящейся в облаке Apple.
В то время как китайским властям ранее приходилось проходить через правовую систему США, чтобы получить доступ к информации китайских граждан, хранящейся в американском дата центре, местный центр данных предоставляет властям более легкий и быстрый доступ к информации о китайских граждан, хранящейся в облаке Apple.

Подключение к оптоволокну и безопасность



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

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

image

Источник: Карта подводных кабелей

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

Facebook инвестировал почти $2B в центр обработки данных в Хенрико, штат Вирджиния, а в январе 2019 года компания Microsoft в шестой раз получила грант в размере $1,5 млн на расширение своего центра обработки данных в Саутсайде, штате Вирджиния.

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

В мае 2016 года Facebook и Microsoft объявили о совместной работе по прокладке подводного кабеля между Вирджиния Бич, Вирджиния и Бильбао, Испания. В 2017 году Facebook объявил о дальнейших планах по строительству собственной волоконно-оптической сети длиной 200 миль в земле в Лас-Лунасе, штат Нью-Мексико, для подключения своего центра обработки данных в Нью-Мексико к другим серверным фермам. Подземная волоконно-оптическая система создаст три уникальных сетевых маршрута для информационного путешествия в Лас-Лунас.

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

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

Центр обработки данных Swiss Fort Knox расположен под Швейцарскими Альпами, дверь которого замаскирована под камень. Его сложная внутренняя система включает в себя множество туннелей, доступ к которым возможен только при соответствующей расчистке. Центр обработки данных защищен аварийными дизельными двигателями и системой воздушного давления, которая предотвращает попадание в помещение ядовитого газа.

image

Форт Нокс Швеции является физически и цифрово-гипербезопасным. Источник: Маунт 10

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

В октябре 2018 года WikiLeaks опубликовала внутренний список объектов AWS. Среди обнаруженной информации был и тот факт, что Amazon была претендентом на создание частного облака стоимостью около $10B для Министерства обороны.

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

В следствии чего WikiLeaks переехала во множество различных дата-центров. В какой-то момент даже ходили слухи, что WikiLeaks рассматривает возможность размещения своего центра обработки данных в океане, в непризнанном государстве Сеаланд в Северном море.

Структура



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

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

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

В любом случае центры обработки данных находятся в центре растущего технологического мира и продолжают испытывать собственные физические трансформации. Согласно инструменту CB Insights Market Sizing, глобальный рынок услуг центров обработки данных оценивается в $228 млрд. к 2020 году.

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

В этом разделе мы рассмотрим периферийные и мегацентры центров обработки данных.

Периферийные центры обработки данных



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

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

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

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

Хотя эта технология еще только зарождается, она уже обеспечивает более эффективный метод обработки данных для многочисленных случаев использования, включая автономные транспортные средства. Например, автомобили Tesla имеют мощные бортовые компьютеры, которые позволяют обрабатывать данные с малой задержкой (практически в режиме реального времени) для данных, собираемых десятками периферийных датчиков автомобиля. Это позволяет автомобилю своевременно принимать самостоятельные решения.)

image

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

В результате этого развертываются меньшие по размеру модульные центры обработки данных для обеспечения гиперлокальных систем хранения и обработки данных. По данным инструмента CB Insights Market Sizing, к 2023 году мировой рынок вычислительной техники достигнет $34B.

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

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

Vapor IO одна из компаний, предлагающая услуги колокейшн, размещая небольшие ЦОДы на базе вышек сотовой связи. Компания имеет стратегическое партнерство с Crown Castle, крупнейшим поставщиком беспроводной инфраструктуры в США.

image

Другие передовые компании центров данных, такие как Edgemicro, предоставляют центры микроданных, которые соединяют операторов мобильной сети (МНС) с провайдерами контента (CPS). Основатели EdgeMicro используют опыт руководителей таких организаций, как Schneider Electric, одна из крупнейших энергетических компаний в Европе, и CyrusOne, один из крупнейших и наиболее успешных поставщиков услуг центров обработки данных в США.
Недавно компания представила свое первое производственное подразделение и планирует продавать свои услуги колокейшн контент-провайдерам, таким как Netflix и Amazon, которые получат выгоду от повышения скорости и надежности доставки контента. Эти колокейшн-сервисы идеально подходят для компаний, которые стремятся владеть, но не управлять своей инфраструктурой данных.

image
Edge Micro

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

image

Huawei

Эти комплексные решений объединяют системы питания, охлаждения, пожаротушения, освещения и управления в одном корпусе. Они предназначены для быстрого развертывания, надежной работы и удаленного мониторинга.

Мегацентры обработки данных



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

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

Одним из крупнейших проектов является объект площадью 17,4 млн кв. футов, построенный компанией Switch Communications, который обеспечивает предприятия жильем, охлаждением, питанием, пропускной способностью и физической безопасностью своих серверов.

image

Switch

В дополнение к этому огромному кампусу Citadel в Тахо Рино, у компания есть так же центр обработки данных площадью 3,5 млн кв. футов в Лас-Вегасе, кампус площадью 1,8 млн кв. футов в Гранд-Рапидс и кампус площадью 1 млн кв. футов в Атланте. Кампус Citadel является крупнейшим в мире центром колокейшн-данных, по данным сайта компаниих.

Big tech также активно строит мега-центры обработки данных в США, с Facebook, Microsoft и Apple все здания для поддержки их растущих потребностей в хранении данных.

Например, Facebook строит дата-центр площадью 2,5 млн кв. футов в Форт-Уэрте, штат Техас, для обработки и хранения личных данных своих пользователя. Предполагалось, что дата-центр будет занимать всего 750 тыс. Кв. Футов, но компания социальных сетей решила утроить свой размер.

image

Источник: Facebook

Новый дата-центр будет стоить около 1 миллиарда долларов и разместится на 150-акровом участке земли, что даст возможность в будущем расширяться. В мае 2017 года было введено в эксплуатацию 440 тыс. Кв. Футов.

Одна из последних инвестиций Microsoft центр обработки данных в Уэст-Де-Мойн, штат Айова, который обошелся компании в 3,5 миллиарда долларов. Вместе этот кластер центра обработки данных занимают 3,2 миллиона квадратных футов пространства, а самый большой центр обработки данных занимает 1,7 миллиона квадратных футов. Этот специальный дата-центр, который называется Project Osmium, расположен на 200 акрах земли, ожидается, что строительство будет завершено к 2022 году.

В последние годы Айова стала популярным местом для центров обработки данных из-за низких цен на энергию (одни из самых низких в стране) и низкого риска стихийных бедствий.

Apple также строит не большой объект в Айове: площадь 400 тыс. кв.футов и его стоимость составит $1,3 млрд.

image
Источник: Apple Newsroom

В то время как некоторые объекты Apple построены с нуля, чтобы управлять всем контентом хранилищем приложений, потоковым музыкальным сервисом, хранилищем iCloud, пользовательскими данными, Apple перепрофилировала завод по производству солнечных панелей площадью 1,3 мв Месе, Аризона, который был открыт в августе 2018 года. Новый центр данных работает на 100% зеленой энергии благодаря расположенной поблизости солнечной ферме.

За пределами США к конкретным регионам, которые привлекли эти мега-центры обработки данных, относится Северная Европа, которая была популярным местом для строительства технологических гигантов благодаря своей прохладной температуре и налоговыми льготами.

Хух-Хото, Китай, расположенный во Внутренней Монголии, также имеет удобное расположение для мега-центров обработки данных, так как есть доступ к дешевой местной энергии, прохладную температуру и университетским талантам (с Inner Mongolia University).

В то время как крупные центры обработки данных стали популярной темой для всего Китая, регион Внутренней Монголии стал центром таких разработок. China Telecom (10,7 млн SF), China Mobile (7,8 млн SF) и China Unicom (6,4 млн SF) создали в этом регионе мега-центры обработки данных.

image

Источник: Worlds Top Data Centers

Инновация центра обработки данных



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

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

Одним из наиболее прогрессивных примеров использования океана с естественным охлаждением является проект Microsoft Project Natick. Как было отмечено в патентной заявке, поданной в 2014 году и названой Погружной центр обработки данных, компания Microsoft погрузила под воду небольшой цилиндрический центр обработки данных побережья Шотландии.

image

В центре обработки данных используется 100% возобновляемой электроэнергии местного производства от береговых ветровых и солнечных источников, а также от морских приливов и волн. Объект использует океан для отвода тепла от инфраструктуры.

image

Источник: Microsoft

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

image

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

Несмотря на то, что Google не сообщал, проводились ли испытания этих конструкций, считается, что компания несет ответственность за плавучую баржу в заливе Сан-Франциско еще в 2013 году.

Запуск Nautilus Data Technologies осуществлялся с очень похожей задумкой. За последние годы компания привлекла $58 млн, чтобы воплотить в жизнь концепцию этого плавучего ЦОДа.

image

Источник: Business Chief

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

Энергоэффективность и экономичность



В настоящее время 3% всего потребления электроэнергии в мире приходится на центры обработки данных, и это процент будет только расти. Это электричество не всегда чистое: по данным Организации Объединенных Наций(ООН), сектор информационных и коммуникационных технологий (ИКТ), который в значительной степени подпитывается центрами обработки данных, обеспечивает такое же количество парниковых газов, что и авиационный сектор с топлива.

Хотя ИКТ удалось сдержать рост потребления электроэнергии отчасти за счет закрытия старых, неэффективных дата-центров, эта стратегия может привести лишь к росту потребления Интернета и производства данных.

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

Снижение потребление и повышение энергоэффективности



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

Операторы центров обработки данных поинтересовались, могут ли они быть реализованы автономно. Однако, согласно Google, ни одна система искусственного интеллекта еще не готова полностью контролировать процессы охлаждения и нагрева в центре обработки данных.

Текущая система управления ИИ компании Google работает над конкретными действиями, но может выполнять их только в ограниченных условиях, приоритетом которых является безопасность и надежность. По данным компании, новая система обеспечивает в среднем до 30% экономии энергии.

image

Типичный день PUE (эффективность использования энергии) при включенном и выключенном ML.
Источник: DeepMind

Компания Google также использовала систему искусственного интеллекта для регулировки эффективности в центре обработки данных на Среднем Западе во время наблюдения за торнадо. В то время как человек-оператор мог сосредоточиться на подготовке к шторму, система ИИ использовала преимущества и знания условий торнадо такими как, падение атмосферного давления и изменения температуры, влажности чтобы настроить системы охлаждения центра обработки данных на максимальную эффективность во время торнадо. Зимой система управления ИИ адаптируется к погоде, чтобы уменьшить потребление энергии, которая необходима для охлаждения центра обработки данных.

Однако этот метод не лишен недостатков. Пробелы в технологии ИИ затрудняют создание условий для того, чтобы центр мог легко принимать эффективные решения, а искусственный интеллект очень трудно масштабировать.Каждый из центров обработки данных компании Google уникален, и трудно развернуть инструмент ИИ( искуственный интеллект) во всех сразу.

Еще один способ повысить эффективность является изменение способа охлаждения перегретых частей центра обработки данных, таких как серверы или определенные типы микросхем.
Один из таких методов заключается в использовании жидкости вместо воздуха для охлаждения деталей. Генеральный директор Google Сундар Пичаи (Sundar Pichai) сказал, что недавно выпущенные чипы компании настолько мощны, что компании пришлось погрузить их в жидкость, чтобы охладить их в нужной степени.

Некоторые центры обработки данных экспериментируют с погружением центров обработки данных под воду, чтобы упростить охлаждение и повысить энергоэффективность. Это позволяет дата-центрам иметь постоянный доступ к естественной прохладной глубоководной воде, поэтому тепло от оборудования уходит в окружающий океан. Поскольку ЦОД может быть размещен у любого побережья, что дает возможность выбрать подключение к экологически чистой энергии как, например, Microsoft Project Natick длиной 40 футов, работающий от ветра сети Оркнейских островов.

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

Однако, несмотря на эти преимущества, некоторые эксперты с осторожностью относятся к центрам обработки данных под водой, так как возможно затопление. Поскольку процесс охлаждения включает в себя втягивание чистой воды и выпуск горячей воды в окружающий регион, эти дата-центры могут сделать море теплее, влияя на местную морскую флору и фауну. И хотя подводные центры обработки данных, такие как Project Natick, предназначены для работы без контроля со стороны человека, в случае возникновения каких-либо проблем их может быть трудно исправить.

В будущем центры обработки данных также могут внести свой вклад в экологически чистую энергию и эффективность за счет утилизации части производимого ими электричества. Некоторые проекты уже изучают возможность повторного использования тепла. Северный центр обработки данных DigiPlex сотрудничает с поставщиком систем отопления и охлаждения Stockholm Exergi для создания системы повторного использования тепла. Концпция этого решения заключается, в то, что бы собирать избыточное тепло в центре обработки данных и отправлять его в местную систему централизованного теплоснабжения, чтобы потенциально обогреть до 10 000 жителей Стокгольма.

Покупка экологически чистых видов энергии



По данным МЭА, индустрия ИКТ добилась определенных успехов в области экологически чистой энергии и в настоящее время закрывает почти половину всех корпоративных соглашений о покупке электроэнергии из возобновляемых источников.

По состоянию на 2016 год Google является крупнейшим покупателем корпоративной возобновляемой энергии на планете.

image

Источник: Google Sustainability

В декабре 2018 года Facebook приобрел 200 МВт энергии у компании которая производит солнечную энергию. В Сингапуре, где площадь суши ограничена, Google объявил о планах купить 60 Мвт солнечной энергии на крыше.

В тоже время крупные компаний, таких как Google и Facebook, у которых есть ресурсы для покупки больших объемов возобновляемой энергии, это может быть трудно для небольших компаний, которые могут не нуждаться в больших объемах энергии.

Еще одним более дорогим вариантом получения энергии является MicroGrid: установка независимого источника энергии внутри центра обработки данных.

Одним из примеров такой стратегии являются топливные элементы, подобные тем, которые продает недавно публичная компания Bloom Energy. Ячейки используют водород в качестве топлива для создания электричества. Хотя эти альтернативные источники часто используются в качестве резервной энергии, центр обработки данных может полностью полагаться на эту систему, чтобы выжить, хотя это эконономически дорогой вариант.

Другой способ, с помощью которого центры обработки данных иследуют экологически чистую энергию, - это использование возобновляемых источников энергии (REC), которые представляют определенное количество чистой энергии и обычно используются для уравновешивания грязной энергии, которую использовала компания. Для любого количества произведенной грязной энергии, REC представляют производство эквивалентного количества чистой энергии в мире. Эти восстановленные суммы затем продаются обратно на рынок возобновляемой энергии.

Однако с моделью REC существуют определенные проблемы. С одной стороны, REC только компенсируют грязную энергию -это не означают, что центр обработки данных работает на чистой энергии. Хотя метод REC, как правило, проще, чем поиск доступных источников, которые могут обеспечить достаточное количество энергии для удовлетворения потребностей центра обработки данных. Минус в том, что метод, как правило, недоступен для небольших компаний, у которых не всегда есть капитал, чтобы делать ставку на колебания солнечной или ветряной электростанции.

В будущем технологии облегчат тесное сотрудничество между мелкими производителями и покупателями. Появляются рыночные модели и портфели возобновляемых источников энергии (подобно тем, которые создаются взаимными фондами), позволяющие оценивать и количественно оценивать колебания возобновляемых источников энергии.

Хранение



Твердотельный накопитель (SSD)



Твердотельные накопители, или SSD, представляют собой разновидность запоминающего устройства, поддерживающего чтение и запись данных. Эти устройства могут хранить данные без питания это называется постоянным хранением. Это отличается от временных форм хранения данных, таких как Random Access Memory (RAM), которые хранят информацию только во время работы устройства.

SSDs накопители конкурируют с HDD еще одной формой массового хранения данных. Основное различие между SSD и HDD заключается в том, что SSD функционируют без движущихся частей. Это позволяет твердотельным накопителям быть более долговечными и легкими.

Тем не менее, SSD накопители остаются более дорогими, чем традиционные HDD диски тенденция, которая, скорее всего, продолжится и без прорыва в процессе производства твердотельных накопителей.

image

Источник: Silicon Power Blog

И хотя твердотельные накопители стали стандартом для ноутбуков, смартфонов и других устройств с тонким профилем, они менее практичны, а, следовательно, менее распространены в крупных ЦОДах из-за их более высокой цены.

image

Источник: Seagate & IDC

По данным IDC, к концу 2025 года более 80% объема корпоративных систем хранения данных останется в виде жестких дисков. Но после 2025 года SSD могут стать предпочтительным средством хранения данных для предприятий и их центров данных.

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

Холодное хранение



В отличие от новых SSD, холодное хранение используют многие старые технологии, такие как CD-R и магнитные ленты, чтобы хранение данных, использовало как можно меньше энергии.

При холодном хранении доступ к данным занимает гораздо больше времени, чем при горячем хранении (например, SSD). В таких системах должны храниться лишь нечасто используемые данные.

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

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

Тем не менее, крупнейшие в мире технологические компании, такие как Facebook, Google и Amazon, используют холодное хранилище для хранения даже самых гранулированных пользовательских данных. Облачные провайдеры, такие как Amazon, Microsoft и Google, также предлагают эти услуги клиентам, которые хотят хранить данные по низким ценам.

Согласно инструменту калибровки рынка CB Insights, рынок холодного хранения, как ожидается, достигнет почти $213B к 2025 году.

habrastorage.org/webt/cr/cc/t-/crcct-u3vtckequtnd0eazlwkqk.png

Источник: IBM

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

Этот тип неиспользуемых данных называется темными данными. Это данные, которые собираются, обрабатываются и хранятся, но обычно не используются для конкретных целей. По оценкам компании IBM, примерно 90% данных датчиков, собранных из Интернета, никогда не используются.

image

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

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

Другие формы хранения данных



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

Одна из перспективных технологий термомагнитная запись (также тепловая магнитная запись) или HAMR. HAMR значительно увеличивает объем данных, которые могут храниться на устройствах, таких как жесткие диски, нагревая поверхность диска с помощью высокоточного лазера во время записи. Это обеспечивает более точную и стабильную запись данных, что увеличивает емкость хранилища.

Ожидается, что к 2020 году эта технология позволит выпускать до 20 ТБ жестких дисков на одном 3,5-дюймовом накопителе, а в дальнейшем ежегодно увеличивать емкость на 30% 40%. Компания Seagate уже создала 3,5-дюймовый диск емкостью 16 ТБ, о чем было объявлено в декабре 2018 года.

В течение последнего десятилетия Seagate активно патентовала эту технологию HAMR. В 2017 году компания подала на рекордное количество патентов, связанных с этой технологией.

(Примечание: Существует 12-18-месячная задержка между подачей патентов и их опубликованием, так что 2018 год может увидеть еще большее число патентов HAMR.)

Немного рекламы :)


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Подробнее..

Как IT гиганты помогают образованию? Часть 2 Microsoft

02.07.2020 12:23:15 | Автор: admin
В прошлом посте я рассказывал, о том, какие возможности предоставляет Google для студентов и образовательных учреждений. Для тех, кто его пропустил, вкратце напомню: я в свои 33 пошёл в магистратуру в Латвии и открыл для себя дивный мир бесплатных возможностей для студентов получить знания от лидеров рынка, а также для преподавателей сделать свои занятия более близкими к рынку. В этом посте речь пойдёт о том, что предлагает студентам и преподавателям Microsoft.


Office 365 для образования


Сколько бы ни существовало различных бесплатных альтернатив, всё же 3 наиболее популярные программы из пакета Office Word, Excel, PowerPoint остаются наиболее удобными, как по мне. LibreOffice всё же немного коряв визуально, а у Google Docs возможности по форматированию чуть поменьше.

К счастью, если Ваша школа или ВУЗ предоставляет Вам электронную почту, Вы можете получить определённый пакет самостоятельно. Централизованно создать аккаунт для учебного заведения, а также ознакомиться с полным списком доступных возможностей можно по ссылке.

Azure для учащихся


Естественно, не обошлось без бонусов для доступа к Azure облачным услугам, предоставляемым Microsoft. Жители более 140 стран могут получить бесплатный доступ к 25 облачным услугам и средствам разработки, а также $100 на баланс, которые можно использовать на другие сервисы. Через 12 месяцев, если Вы всё ещё студент, сумму и срок действия можно обнулить.

Преподавателям традиционно предлагается сумма побольше $200. Материалы для практических работ доступны всем желающим.

Для получения плюшек опять-таки нужен e-mail образовательного учреждения, зато не нужна кредитная карточка (напомню, что она требуется для регистрации обычного trial аккаунта). Но и это ещё не всё. В пакет также входят некоторые приятные плюшки:

Обучающие материалы


Внутри кабинета Azure для учащихся доступны короткие практические обучающие материалы, позволяющие раскрыть и пощупать шаловливыми ручками возможности платформы. Отличное применение для начисленных $100.



Инструменты и средства для разработки


Список тут довольно обширный. Из того, что заинтересовало меня: Visual Studio 2019 Enterprise (использовал на одном из предметов, т.к. нужные возможности CLion не завелись), Microsoft Visio, Microsoft Project (пригодились на другом предмете), Windows 10 Education (просто пригодилась), серверные версии Windows



WintellectNOW


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



Pluralsight


Ещё одна подборка курсов, более интерактивная. Доступ предоставляется лишь к ограниченному набору курсов, спонсированному Microsoft. Тут также встречаются темы как общей направленности, так и конкретно по работе с возможностями Azure.



Microsoft Learn


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

Центр преподавателей


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

Вместо заключения


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

От себя хотим также предложить всем студентам скидку 50% на первый год использования наших услуг хостинга и облачных VPS, а также VPS с выделенными накопителями. Для этого Вам необходимо зарегистрироваться у нас, сделать заказ и, не оплачивая его, написать тикет в отдел продаж, предоставив фото себя со своим студенческим. Сотрудник отдела продаж скорректирует Вам стоимость заказа в соответствии с условиями акции.

И опять другой рекламы не будет.
Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru