По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой статье мы расскажем как исправить ошибку «System logs are stored on non-persistent storage» (Ваши события не будут сохранены при отключении сервера) в VMware ESXi
Решение
Проверка местоположения системных событий в vSphere Client (HTML5)
В навигаторе vSphere Client выберите Hosts and Clusters view.
Выберите хост-объект в навигаторе vSphere Client.
Нажмите на вкладку Configure, затем System expander.
В разделе System выберите Advanced System Settings.
Убедитесь в том, что параметр Syslog.global.logDir в качестве местонахождения указывает постоянное хранилище.
Если поле Syslog.global.logDir пустое или указывает на scratch partition, убедитесь, что поле ScratchConfig.CurrentScratchLocation в качестве местонахождения указывает постоянное хранилище.
Если папка используется в качестве хранилища scratch, которое является общим для большого количества ESXi хостов, вам также необходимо установить поле Syslog.global.logDirUnique,чтобы избежать конкуренции лог-файлов.
Примечание: Чтобы войти в datastore, запись Syslog.global.logDir должна быть в формате [Datastorename]/foldername. Чтобы войти в scratch partition в ScratchConfig.CurrentScratchLocation введите пустой формат или []/foldername.
Версии ESXi 6.5, 6.7 и выше реагируют на изменения незамедлительно. Более старым версиям для этого может потребоваться перезагрузка.
Проверка местоположения системных событий в vSphere Web Client
Перейдите к хосту в навигаторе vSphere Web Client.
Нажмите вкладку Manage, затем Settings.
В разделе System выберите Advanced System Settings.
Убедитесь в том, что параметр Syslog.global.logDir в качестве местонахождения указывает постоянное хранилище.
Если поле Syslog.global.logDir пустое или указывает на scratch partition, убедитесь, что поле ScratchConfig.CurrentScratchLocation в качестве местонахождения указывает постоянное хранилище.
Если папка используется в качестве хранилища scratch, которое является общим для большого количества ESXi хостов, вам также необходимо установить поле Syslog.global.logDirUnique,чтобы избежать конкуренции лог-файлов.
Проверка местоположения системных событий в vSphere Client (vSphere 6.0 и более ранние версии)
В программе vSphere Client выберите хост на инвентарной панели.
Нажмите на вкладку Configuration, затем – на Advanced Settings в разделе Software.
Убедитесь в том, что параметр Syslog.global.logDir в качестве местонахождения указывает постоянное хранилище. У каталога должны быть название и путь к хранилищу данных [datastorename] path_to_file. Например, [datastore1] /systemlogs.
Если поле Syslog.global.logDir пустое или указывает scratch partition в качестве хранилища, убедитесь, что поле ScratchConfig.CurrentScratchLocation указывает в качестве местонахождения постоянное хранилище.
Дополнительная информация
Если вы видите, что работающий хост сохраняет информацию в хранилище scratch в формате >UUID (/vmfs/volumes/xxxxxxxx-xxxxxxxx-xxxx-xxxxxxxxxxxx/foldername) и хотите, чтобы имя «friendly» отобразилось в вашем vCenter или host client view, вы можете:
Подключиться к рабочему хосту через сеанс SSH и войти в систему с учетными данными root
Использовать команду: # esxcli storage filesystem list. Выход будет приблизительно таким:
/vmfs/volumes/ad495351-37d00fe1-c498-a82a72e0c050 abc-lun3 ad495351-37d00fe1-c498-a82a72e0c050 true VMFS-5 805037932544 400613703680
В этом примере abc-lun3 – это имя «friendly» хранилища данных, которое вы найдете в вашем vCenter или host client, и запись Syslog.global.logDir должна быть в формате [abc-lun3]/foldername.
Чтобы понять NoSQL, нужно разобраться, что такое SQL и почему мы говорим ему No.
Итак, SQL (structured query language) расшифровывается как «язык структурированных запросов», и это язык запросов для управления данными в так называемых реляционных базах данных, или просто БД
В реляционных базах мы храним данные в таблицах, которые логически связаны между собой - отсюда и название - реляционные от слова relation, связь. Это один из самых популярных типов баз.
В этих таблицах есть строки и столбцы. В столбце таблицы хранится определенный тип данных, а в каждой ячейке – значение.
Строка же получается как набор связанных значений, которые относятся к одному объекту - мы видим что у крыла типа чайка длина 25 метров.
Ну и каждая строка в таблице может быть помечена каким то уникальным идентификатором, который называется первичным ключом (primary key). А затем при помощи него мы можем связать данные из нескольких таблиц, например в отдельной таблице, где он станет внешним ключом (foreign key).
В общем, как таблица в экселе, только данные могут быть связаны.
Что еще важно знать: реляционные БД требуют так называемую схему (schema) - описание структуры таблицы ее полей и ограничений. То есть если нам например нужно добавить или убрать столбец в таблице, то это изменение коснется всех данных внутри нее.
Также БД этого типа соответствуют так называемым принципам ACID (Atomicity — Атомарность, Consistency — Согласованность, Isolation — Изолированность, Durability — Надёжность), что вкратце означает, что при работе с базой, целостность и согласованность данных гарантирована, даже если возникли проблемы с сетью или железом, что полезно при работе с финансами, например.
В качестве примеров таких баз назовем: Microsoft SQL Server, Oracle Database, MySQL и PostgreSQL.
Разобрались. Теперь вернемся к NoSQL. Это тип баз данных, которые хранят данные в отличном от реляционных таблиц формате. Они узкоспециализированны для конкретных задач и нужны для улучшения производительности, масштабируемости и удобства в работе.
Базы данных "ключ-значение" (key-value)
Суть в том, что мы храним данные в таком виде: у нас есть уникальный ключ, который указывает на какое-то значение. А сама база - это совокупность этих пар. Вот так просто! Причем эти данные могут быть чем угодно, числом, строкой или даже другой парой ключ-значение потому что в отличии от реляционных баз данных они не имеют предопределенной структуры данных.
Многие БД такого типа хранят данные в памяти (RAM), в отличии от других баз, которые хранят данные на диске, что хоть и может ограничивать объем хранимых данных (хотя они требуют гораздо меньше памяти), но это обеспечивают просто невероятную скорость. Ну и раз это NoSQL то никаких сложных запросов, никаких связей друг с другом - мы просто записываем ключ и его значение, и получаем значение по ключу.
Где их использовать? Они отлично подходят для хранения кэша или пользовательских сессий. А в качестве самого простого примера можно назвать корзину в интернет магазине - где мы храним идентификатор пользователя, и сколько товаров он положил в корзину.
Самые популярные хранилки по типу “ключ - значение” это Redis, Memcached и DynamoDB.
Wide-column (columnstore базы данных, БД с широкими столбцами или колоночные БД)
Все также просто - берем key-value БД, и делаем так чтобы в значении мы могли хранить несколько столбцов сразу. Это позволяет удобно хранить связанную информацию. Похоже на реляционную БД, но только в отличии от нее, тут у нас нет схемы, поэтому мы можем хранить разные неструктурированные данные.
Такой тип БД подойдет для хранения логов, данных с умных холодильников и чайников, а также различных аналитических приложений, где данные хранятся в большом объеме. Netflix, например, хранит в таких таблицах историю просмотров пользователя.
В качестве примеров таких баз назовем Cassandra, Hbase и ClickHouse.
Базы данных документов или документориентированные БД (Document DB)
Подробнее про них можно прочитать в нашей отдельной статье.
Если предыдущие типы NoSQL БД обычно используются для специфических задач, то эти базы уже более универсальны, и могут стать основным местом хранения информации.
Здесь мы храним документы. Документ это набор нескольких пар ключ-значение, о которых мы говорили раньше, и раз это не SQL, то они неструктурированны и не требуют схему. Это значит, что мы можем легко добавлять и удалять поля в документе, в отличие от реляционных БД, где изменения затронули бы всю таблицу. Документы даже могут быть вложенными, и содержать в себе другие документы.
Данные хранятся в стандартных форматах, таких как XML, YAML и JSON. Такая форма хранения идеально подходит к объектам, которые используются в приложениях. Мы буквально сразу получаем полный объект который нам нужен, а в SQL нужно сначала приложить усилия и даже сделать несколько запросов и все собрать в необходимый вид.
Документы можно группировать друг с другом собирая их в коллекции, которые можно собирать в логическую иерархию, получая что-то по типу реляционных БД.
Это как шкаф на работе - в один ящик мы можем положить трудовые договоры, в другой - договоры с партнерами, а в третий договоры аренды.
Ничто нам не мешает сложить всё в одну кучу, но так удобнее. И вот эти ящики как раз и будут коллекциями в нашем случае. А отсутствие схемы позволяет нам положить в один ящик договоры, которые схожи логически, но имеют разную структуру внутри. Например, долгосрочный договор с сотрудником и договор с компанией. Коллекции есть не у всех БД такого типа, некоторые системы используют теги или древовидные иерархии.
Они часто используются для мобильных приложений и игр, блогов, интернет магазинов и всяких штук где у нас имеется много контента.
Самые популярные БД такого типа - MongoDB, Amazon DynamoDB, CouchDB.
Графовые БД (Graph DB)
Тут мы больше значения уделяем тому как данные связаны друг с другом, и эта БД лучше всего обрабатывает такие данные.
Тут у нас есть узлы, которые представляют данные и ребра (или соединения), которые описывают связь между этими данными. Помните как в реляционных базах мы записывали связь в отдельной таблице? Тут мы можем обойтись без нее, просто показав связь.
Такие базы просто необходимы для алгоритмов рекомендаций, социальных сетей, управления компьютерными сетями и маршрутизацией или даже обнаружения финансового мошенничества.
Самые популярные графовые базы: Neo4j и DGraph
Поисковые БД (Search-engine database)
Они, как понятно из названия, нужны для поиска данных из большого количества источников.
Работают они примерно также как и базы данных документов - мы добавляем документы с текстом внутри, а БД проанализирует весь текст в этих документах и создаст индексы для этого текста.
По сути это работает как указатели, которые ты видел в конце книги, где указывается какой-то термин и страница на которой он встречается.
И когда пользователь выполняет поиск, то сканируются только эти индексы, а не все документы в базе.
Ну и очевидно что они используются в качестве полнотекстового поиска, а также для хранения и анализа логов. Примеры - Elasticsearch, Solr, Algolia
Базы данных временных рядов (Time series database)
Это базы данных, оптимизированные для данных с отметками времени. Такое используется, для мониторинга систем, где мы храним значение времени и данные в этот момент. Например, загрузка сервера или количество подключений.
Примеры - InfluxDB и Prometheus
Многомодульные БД (multi-model)
Также существуют так называемые много-модульные БД (multi-model), которые поддерживают несколько моделей данных.
Например тот же рredis умеет и в ключ-значение, и документы с графами и даже временные данные обработает.
Давайте рассмотрим следующую ситуацию: Санта приносит игрушки всем хорошим девочкам и мальчикам.
На 2019 год в мире проживало 7 713 468 100 человек, около 26,3% из которых моложе 15 лет. Это 2 028 642 110 детей (лиц в возрасте до 15 лет) в мире.
Есть такое мнение, что Санта посещает детей не всех религий, поэтому мы обобщим и включим в рассмотрение только христиан и нерелигиозных людей. В совокупности это примерно 44,72% населения. Если мы предположим, что дети исповедуют ту же религию, что и родители, то получится, что Санта-Клаус должен посетить 907 208 751,6 детей.
Какой процент из этих детей хорошие? Это узнать невозможно; однако мы можем поработать с несколькими предположениями. Во-первых, Санта-Клаус действует больше из соображений оптимизма, а не экономии, так что, он, вероятно, был бы готов к возможности того, что каждый ребенок будет хорошим в любой год. Таким образом, он был бы готов дать игрушку каждому ребенку. Предположим, что это был отличный год и все 907 208 751,6 детей получили игрушки.
Подарков много, и, как мы знаем, все они сделаны эльфами Санты в его мастерской на Северном полюсе. Учитывая, что в году 365 дней, и один из них – Рождество, то будем считать, что у Санты есть 364 дня, чтобы сделать и упаковать 907 208 752 (округлим) подарка. Получается 2 492 331,74 подарка в день.
Почти два с половиной миллиона подарков в день – большая нагрузка для любой мастерской. Давайте рассмотрим два подхода, которые Санта может использовать, чтобы упаковать все подарки: конкурентное исполнение (конкурентность) и параллельное исполнение (параллелизм).
Последовательный процесс
Предположим, что в мастерской Санты-Клауса работает ровно один очень трудолюбивый и очень уставший эльф. Один подарок изготавливается за четыре этапа:
Раскрой дерева
Сборка и склейка игрушки
Роспись игрушки
Подарочная упаковка
Когда эльф только один, то в любой момент времени он может выполнять лишь один этап для одного подарка. Если бы эльф производил по одному подарку от начала и до конца, то этот процесс был бы последовательным. Но это не самый эффективный способ для того, чтобы изготовить два с половиной миллиона подарков за день. Например, эльфу придется ждать и при этом ничего не делать, пока клей на игрушке не высохнет, и он сможет перейти к следующему этапу.
Конкурентность
Для того, чтобы быть более продуктивным, эльф может работать над всеми подарками одновременно.
Вместо того, чтобы делать по одному подарку за раз, эльф сначала раскраивает всю древесину для всех игрушек, одну за другой. Когда все вырезано, эльф собирает и склеивает игрушки одну за другой. При такой одновременной обработки клей на первой игрушке успевает высохнуть (не требуя особого внимания со стороны эльфа), пока склеиваются другие игрушки. То же самое касается росписи и упаковки.
Так как один эльф может выполнять только одну задачу за раз, то, если он будет производить подарки одновременно, он будет использовать день максимально эффективно.
Параллелизм
Хотелось бы надеяться, что в мастерской Санты все же больше, чем один эльф. Чем больше эльфов, тем больше игрушек можно сделать одновременно в течение дня. Такая одновременная работа означает, что подарки производятся параллельно. Параллельная работа нескольких эльфов означает, что одновременно выполняется больше работы.
Эльфы, которые работают параллельно, также могут использовать конкурентность. Один эльф по-прежнему может решать только одну задачу за раз, поэтому самым эффективным вариантом будет иметь несколько эльфов, которые будут производить подарки одновременно.
Конечно, если в мастерской Санты, скажем, два с половиной миллиона эльфов, то тогда каждый эльф должен будет сделать максимум один подарок за день. В таком случае последовательная работа не снижает эффективности. И осталось бы еще 7 668,26 эльфов, которые приносили бы кофе и обед.
Санта-Клаус и многопоточность
После того, как эльфы выполнили всю тяжелую работу, Санта-Клаус должен доставить подарки – все 907 208 752.
Санте не нужно навещать каждого ребенка лично; только елку в доме. Итак, сколько же елок ему нужно посетить? Опять же, обобщая, мы скажем, что среднее количество детей в семье во всем мире составляет 2,45 (будем основываться на прогнозируемых коэффициентов рождаемости на этот год). Получается, что Санта должен посетить 370 289 286,4 дома. Давайте округлим до 370 289 287.
Сколько на это есть времени у Санты? Легенды гласят об одной ночи, что означает один оборот Земли, а, значит, 24 часа. NORAD это подтверждает.
Это значит, что Санта должен посетить 370 289 287 домов за 24 часа (86 400 секунд). Следовательно, его скорость должна составлять 4 285,75 домов в секунду, и мы еще не упоминали о, которое нужно для того, чтобы положить подарки под елку и взять печенье.
Понятно, что Санты в нашем измерении не существует. Хотя бы потому, что он достаточно пухлый и при этом он пролезает в дымоход (с зажженным огнем, оставаясь невредимым) с мешком игрушек для всех детей семьи. И это мы еще не учли тот факт, что его сани везут огромное количество игрушек для каждого верующего ребенка во всем мире и что они летают.
Существует ли Санта вне наших законов физики? Как мог кто-то реальный путешествовать по миру, доставляя посылки менее чем за 24 часа со скоростью 4 285,75 домов в секунду, и при это у него еще оставалось время на молоко, печенье и поцелуй мамочки?
Одно можно сказать наверняка: Санта пользуется Интернетом. Никакая другая технология еще не позволяла посылкам перемещаться так далеко и так быстро. Как бы там ни было, попытка охватить более четырех тысяч домов в секунду – непростая задача, даже имея в арсенале лучшее гигабитное Интернет-соединение, которое может предоставить Северный полюс. Как Санта может повысить свою эффективность?
Очевидно, что у этой загадки есть только один логичный ответ: Санта-Клаус – это многопоточный процесс.
Один поток
Давайте посмотрим на это все со стороны. Представим, что поток – это одна конкретная задача или детализированная последовательность инструкций, которую может выполнить Санта. Один поток может выполнить только одну задачу – положить подарок под елку. Поток – это некий компонент процесса, в данном случае процесса доставки подарков Санта-Клаусом.
Если бы Санта-Клаус был бы однопоточным, то он как любой однопоточный процесс мог бы выполнять лишь одну задачу за раз. Поскольку он стар и у него не такая хорошая память, то у него, вероятно, есть набор инструкций по доставке подарков, а также график, которого стоит придерживаться. Эти две вещи направляют поток Санты, пока его процесс не завершится.
Однопоточный Санта-Клаус работает примерно по следующей схеме:
Посадить сани у дома Тимми.
Достать подарок Тимми из саней.
Войти в дом через дымоход.
Найти рождественскую елку.
Положить подарок Тимми под рождественскую елку.
Выйти из дома через дымоход.
Взлететь на санях.
И так по кругу… еще 370 289 286 раз.
Многопоточность
Многопоточный Санта-Клаус, напротив, является доктором Манхэттеном Северного полюса. В мире существует все еще один Санта-Клаус, но у него есть удивительная способность размножить свое сознание и одновременно выполнять несколько наборов инструкций. Эти дополнительные рабочие задачи, или рабочие потоки, создаются и контролируются основным процессом доставки подарков Санта-Клауса.
Каждый рабочий поток действует независимо, выполняя свои инструкции. Так как все они являются копией сознания Санты, то у них есть его память, и они знают все, что знает Санта, в том числе то, как устроена планета, по которой они доставляют подарки, и откуда эти подарки брать.
Благодаря этим знаниям каждый поток может выполнять свой набор инструкций параллельно с другими потоками. Такой многопоточный параллелизм делает единственного и неповторимого Санта-Клауса максимально продуктивным.
Если в среднем выполнение доставки подарка занимает час, то Санте нужно создать всего 4 286 рабочих потоков. Совершая по одной доставке в час таким образом, Санта завершит все 370 289 287 поездок к концу ночи.
Конечно, чисто теоретически, Санта может создать даже 370 289 287 рабочих потоков, каждый из которых займется одним домом, чтобы доставить подарки всем детям! Это сделало бы Санту максимально продуктивны, а также объяснило бы, как ему удается съесть все эти печеньки с молоком, не объевшись. ????
Эффективное и счастливое многопоточное Рождество
Благодаря современным компьютерам мы наконец-то понимаем, как Санта-Клаус справляется с, казалось бы, невыполнимой задачей доставки игрушек хорошим девочкам и мальчикам по всему миру. От моей семьи вашей семье, я надеюсь, вы проводите отличное Рождество. И не за будьте повесить носки на полку маршрутизатора.
Конечно, все это никак не объясняет, как же все-таки северным оленям удается летать.