Открыть пхп сторм
загрузить в него мой сайт
потом сделать лого фавикон и переверстать хедер
в хедер добавить телефон,подпись куда попал(типа асфальтирование)
Потом сделать чтоб это все нормально отображалось в мобильных
Потом сделать ссылку на Г+
Перед этим сделать сам Г+
Потом есть шаблон в странице отзывов и нужно сделать так чтоб там отображались отзывы с файсбука например
В самом низу сделать ссылку на нас в социальных сетях.Ну и такое.сайп почта и т д
Затем нужно сделать чтоб сайт при клике вызывал ДОВЕРИЕ.
Нужно подобрать доверительную цветовую схему
вторник, 26 июля 2016 г.
вторник, 19 июля 2016 г.
Отличие vmware vmotion vs storage vmotion vs enchansed vmotion в чем их разница
Отличие vmware vmotion vs storage vmotion vs enchansed vmotion в чем их разница что лучше что для чего нужно
Давайте сначала поговорим о vmotion.Сразу оговорюссь статью пишу лично для себя так что если что кому не понравится то идите нахуй.
Итак.vmotion(вмоушн буду его называть чтоб лишний раз не переключать клавиатуру).
вмоушн можно самому использовать но его использует в основном ДРС(vmware drs)
все физические файлы,виртуал диски и конф файлы лежат на централизованном сторедже(который нужен обязательно для вмоушн,на локале тоже лежат конечно же).соответственно перенос одной виртуалки с одного есх на другой сводится к тому чтоб сделать слепок памяти.и перенести его на друго ЕСХ.да и все.
слепок переносится по vmotion network которую видят все хосты но которая изолирована от продакшн сети( с помошю виртуального влана или как то так).между хостами обязательно должна быть гигабитка.и никак иначе! при 10 гигабитах можн оделать 4 вмоушн
https://www.youtube.com/watch?v=YH0he0nz8Mg&spfreload=5 - вот тут рассказано про вмоушн
кароче только память!!и все!!
ну и конечно для вмоушн как и для всего остального лучше иметь на разных ЕСХ одинаковые процы и схожую а лучше одинаковую конфигурацию!
нужно иметь сконфигурированный ВМКернел порт( как и для хранилища)
Теперь оффтоп потому что дальше по плейлисту пошел видос про VMFS datastore
Кароче есть NFS датастор - простоей сервак НФС - и он кстати работает для вмоушн,для ХА и для ДРС
Если же брать ВМФС то нужен диск доступный по сети.Так называетмое устройство ЛУН(фибрченнел диск,айскази и т д)
https://www.youtube.com/watch?v=YH0he0nz8Mg&spfreload=5
Тонкий и толстый провижнинг - просто если выбирать толстый то если создаешь виртуалку то толстый будет заниматься все место(аллокейт те будет предварительно считать это место занятым)если же делать тонкий то виртуальный диск будет расти по мере его загрузки.
Самое главное в этом провижнинге - это АЛЕРТЫ.когда будет забито 75% места он начнет давать алерты.когда 85 то типа будет орать шопесдец.Ну и да - это экономит место.
Сторедж ДРС - тоже самое что и ДРС только для стореджей.Есть 2 параметра.Забитость места и ИО лейтенси.Те сколько места осталось и как нагружено ИО этого стореджа.
Соответствеено говоря если что сторедж ДРС переносит ВМики в другие датастореджи если начинает стореджу наступать пиздец.
Точно также он делает это в автомате но может и в мануале давать рекомендации
ВООБЩЕ ЕСТЬ ДАТАСТОР КЛАСТЕР:я так понимаю это кластер из локалстореджей(локальных дисков) и также всяких фиберченнелов и т д
и вот ДРС и ганяет в этом кластере файлы этих ВМ
И СОБСТВЕННО ГОВОРЯ СТОРАДЖ ДРС ИСПОЛЬЗУЕТ Сторедж вМоушн ДЛЯ ТОГО ЧТОБ ГАНЯТЬ ВСЕ ЭТО!!!!понятно!!!!
те как дрс использует вмоушн так и сторедж дрс использует сторедж вмуощн
Немного про датасторы:
датастор это винт или же хранилище сетевое(только НЕ НФС) отформтированное в файловую систему ВМФС(ВМФС - дейтастор) .там могут храниться 3 вещи:винты виртуалок,темплейты виртуалок,исо файлы с образами.
под ВМФС может быть отформатирован как и локальный винг(ЕСХ по умолчанию) так и удаленка айСкази и фиберченнел
АГА.те когда мы создаем виртуалку.мы можем прикрепить к ней дататор он может быть как в этой виртуалке(ее витуальный диск) так и в другой месте!!!
ТЕ когда создаем виртуалку.можем ее харддиски создавать не на том месте где ее создаем а они (сами файлы ВМДК) будут храниться на другом месте и она будет делат операции записи не на локальный ХДД а на удаленку хотя она будет думать что на локальный.Это получается еще один уровень асбтракций.
Сторедж профайлы:
например у нас есть несколько серваков с ЕСХ
на некоторых есть репликация а на некоторых нет
у нас есть виртуалки на этиъ ЕСХ
есть критичные виртуалки и нужно чтоб их вирртуальные винты были в сохранности
а есть некритичные которые похуй.есть бекам.нет бекапа.есть шаблон и т д
так вот.Есть сторедж профайлы.
создаем 2 профайлы.один - репликейтед(название) второй - нерепликейтед
потом указываем какие ЕСХ или же стореджи у нас репликейтед а какие нет
И ПОТОМ КОГДА СОЗДАЕМ ВИРТУАЛКИ УКАЗЫВАЕМ ПРОФТЛЬ
и тогда критичная виртуалка будет показывать что она не нерепликейтеде!
ТЕ Можно сохдть на нерепликетеде НО БУДЕТ ВИСЕТЬ ЕРРОР и АЛЕРТ
что типа можно потерять данные
https://www.youtube.com/watch?v=7mawQTuTw4I - вот видос
Давайте сначала поговорим о vmotion.Сразу оговорюссь статью пишу лично для себя так что если что кому не понравится то идите нахуй.
Итак.vmotion(вмоушн буду его называть чтоб лишний раз не переключать клавиатуру).
вмоушн можно самому использовать но его использует в основном ДРС(vmware drs)
все физические файлы,виртуал диски и конф файлы лежат на централизованном сторедже(который нужен обязательно для вмоушн,на локале тоже лежат конечно же).соответственно перенос одной виртуалки с одного есх на другой сводится к тому чтоб сделать слепок памяти.и перенести его на друго ЕСХ.да и все.
слепок переносится по vmotion network которую видят все хосты но которая изолирована от продакшн сети( с помошю виртуального влана или как то так).между хостами обязательно должна быть гигабитка.и никак иначе! при 10 гигабитах можн оделать 4 вмоушн
https://www.youtube.com/watch?v=YH0he0nz8Mg&spfreload=5 - вот тут рассказано про вмоушн
кароче только память!!и все!!
ну и конечно для вмоушн как и для всего остального лучше иметь на разных ЕСХ одинаковые процы и схожую а лучше одинаковую конфигурацию!
нужно иметь сконфигурированный ВМКернел порт( как и для хранилища)
Теперь оффтоп потому что дальше по плейлисту пошел видос про VMFS datastore
Кароче есть NFS датастор - простоей сервак НФС - и он кстати работает для вмоушн,для ХА и для ДРС
Если же брать ВМФС то нужен диск доступный по сети.Так называетмое устройство ЛУН(фибрченнел диск,айскази и т д)
https://www.youtube.com/watch?v=YH0he0nz8Mg&spfreload=5
Тонкий и толстый провижнинг - просто если выбирать толстый то если создаешь виртуалку то толстый будет заниматься все место(аллокейт те будет предварительно считать это место занятым)если же делать тонкий то виртуальный диск будет расти по мере его загрузки.
Самое главное в этом провижнинге - это АЛЕРТЫ.когда будет забито 75% места он начнет давать алерты.когда 85 то типа будет орать шопесдец.Ну и да - это экономит место.
Сторедж ДРС - тоже самое что и ДРС только для стореджей.Есть 2 параметра.Забитость места и ИО лейтенси.Те сколько места осталось и как нагружено ИО этого стореджа.
Соответствеено говоря если что сторедж ДРС переносит ВМики в другие датастореджи если начинает стореджу наступать пиздец.
Точно также он делает это в автомате но может и в мануале давать рекомендации
ВООБЩЕ ЕСТЬ ДАТАСТОР КЛАСТЕР:я так понимаю это кластер из локалстореджей(локальных дисков) и также всяких фиберченнелов и т д
и вот ДРС и ганяет в этом кластере файлы этих ВМ
И СОБСТВЕННО ГОВОРЯ СТОРАДЖ ДРС ИСПОЛЬЗУЕТ Сторедж вМоушн ДЛЯ ТОГО ЧТОБ ГАНЯТЬ ВСЕ ЭТО!!!!понятно!!!!
те как дрс использует вмоушн так и сторедж дрс использует сторедж вмуощн
Немного про датасторы:
датастор это винт или же хранилище сетевое(только НЕ НФС) отформтированное в файловую систему ВМФС(ВМФС - дейтастор) .там могут храниться 3 вещи:винты виртуалок,темплейты виртуалок,исо файлы с образами.
под ВМФС может быть отформатирован как и локальный винг(ЕСХ по умолчанию) так и удаленка айСкази и фиберченнел
АГА.те когда мы создаем виртуалку.мы можем прикрепить к ней дататор он может быть как в этой виртуалке(ее витуальный диск) так и в другой месте!!!
ТЕ когда создаем виртуалку.можем ее харддиски создавать не на том месте где ее создаем а они (сами файлы ВМДК) будут храниться на другом месте и она будет делат операции записи не на локальный ХДД а на удаленку хотя она будет думать что на локальный.Это получается еще один уровень асбтракций.
Сторедж профайлы:
например у нас есть несколько серваков с ЕСХ
на некоторых есть репликация а на некоторых нет
у нас есть виртуалки на этиъ ЕСХ
есть критичные виртуалки и нужно чтоб их вирртуальные винты были в сохранности
а есть некритичные которые похуй.есть бекам.нет бекапа.есть шаблон и т д
так вот.Есть сторедж профайлы.
создаем 2 профайлы.один - репликейтед(название) второй - нерепликейтед
потом указываем какие ЕСХ или же стореджи у нас репликейтед а какие нет
И ПОТОМ КОГДА СОЗДАЕМ ВИРТУАЛКИ УКАЗЫВАЕМ ПРОФТЛЬ
и тогда критичная виртуалка будет показывать что она не нерепликейтеде!
ТЕ Можно сохдть на нерепликетеде НО БУДЕТ ВИСЕТЬ ЕРРОР и АЛЕРТ
что типа можно потерять данные
https://www.youtube.com/watch?v=7mawQTuTw4I - вот видос
четверг, 14 июля 2016 г.
про vmware
у них счас есть куча продуктов
был ESX и ESXi остался только ESXi у ЕСХ была встроенная констол.ЕСХи нужно
управлять только через вСфера
вСфера это клиент который может коннектится как к отдельному ЕСХи так и с вЦентр
вЦентр это сервак(устанавливается только на виндовс помоему) куда все серваки ЕСХи подконнекчены и оттуда можно переонсить виртуалки(в работающем состоянии) - это вМоушн
или даже их ХДД те переносим работающую виртуалку с работающим ХДД на другой ЕСХи - это всМоушн
так же был ВМВАРе -сервер но его уже нет.вернее есть и даже доступен на скачивание но его по факту не выпускают так как есть Фри ЕСХи (я так понимаю он отличается там что не тулится в вСферу и его админиить можно только отдельпо заходя на него с помощю вЦентр)
инВижн - это воркстейщн только для Мак
вЦентр - ставится только на виндоус сервере(2008 минимум помоему)
есть жеж вЦентр Виртуал Аплаенс - это для линуха(это я так понимаю уже настроеная виртуалка,просто ее запускаем,коннектимся на вебморду,подстраиваем немного а потом уже вСфер клиентом лезем на нее и туда коннектим ЕСХи да и делов)
https://www.youtube.com/watch?v=YSSQnAoiFtg вот тут видео про это все
В вЦентре все просто.устанавливаем его образ на машину
потом коннектимся в него вСферой.Потом создаем новый датацентр.потом добавляем ЕСХи вписываем логи пароль и айпишник(можно ДНС)
кароче после того как добавили можем там подключать НФС или по АЙСКАЗИ винты.по поводу сети можем подключать сети с вланИД также там есть вСвитч кароче вмы могут между собой общаться а также внутри ЕСХ сервера может быть типа виртуальный вСвич и там могут быть несколько виртуалок общаться между собой или быть разбиты на группы и изолированы с помощю вланов
что нового в 6 вСфере:https://www.youtube.com/watch?v=0B3hDris8CM
тут про НУМА и про НУМА в ЕСХи https://habrahabr.ru/post/122535/
С помощью компонента vSphere Fault Tolerance (FT) поддерживайте непрерывную доступность приложений (на четырех виртуальных процессорах) в случае сбоев на сервере. Она создает фоновый экземпляр работающей виртуальной машины, в точности соответствующий основной ВМ. При отключении питания функция vSphere FT автоматически инициирует аварийное переключение. Будет создана и запущена резервная виртуальная машина, что обеспечит непрерывную защиту приложения. Данная технология совместима со всеми типами общих систем хранения данных и всеми операционными системами, поддерживаемыми платформой vSphere.
вообще тут про ХА http://itband.ru/2010/06/vsphere-ha-cluste/
а тут типа глубокое ХА http://itband.ru/2009/12/vmware-slots/
достаточно легко если что
тут про разницу между фолт толеранс и хай авиабилити
http://searchvmware.techtarget.com/essentialguide/Avoiding-downtime-with-VMware-Fault-Tolerance-and-High-Availability
я так понимаю что проблема у ФТ в том чтоб в виртуалках которые в ФТ им выделяют только один виртуальный процессор
Так.для ХА нужно правильно расчитівать Failover Capacity - єто смогут ли остальніе ЕСХи серваки в кластере,вернее будет ли у них место на винтах,процессорі и память ,она расчитівается по спцец формуле.Потом опять же должно біть хранилище с гигабитной сетью(в самом плохом случае єто НФС)
ТЕПЕРЬ ЧТО ТАКОЕ вМОУШН(я знаю что єто такое НО БЛЯТЬ НАХУЯ ОНО НУЖНО!!0) и что такое ДРС
http://www.vm4.ru/2007/10/vmotion.html - вот тут детально описание вМОУШН
вообще ОН СУЩЕСТВУЕТ ТОЛЬКО ДЛЯ ПЕРЕНОСА ВМ НА ДРУГОЙ ЕСХи без остановки работы!причем перенос идет так:
Тыкаем правой кнопкой в ВМ, выбираем Migrate. Если ВМ включена - этот пункт и запустит VMotion. Выбираем хост, на который хотим смигрировать. Процесс начинается. Если все условия выполнены - скорее всего :) он заканчивается нормально.
По поводу того, что из себя представляет сам процесс, и что идет через сеть VMotion -
Как только мы запускаем миграцию, память нашей ВМ блокируется на запись. ВМ продолжает работать, но все изменения в ее оперативке пишутся "рядом" с заблокированным массивом.
Теперь эта память передается на другой ESX. Именно через интерфейс vmkernel, который мы задействуем под VMotion.
Как только вся передалась - ВМ блокируется полностью - и на второй ESX передается область памяти с изменениями. Т.к. он почти наверняка будет небольшой - время в течении которого ВМ полностью блокируется также невелико. Весьма невелико.
На этом этапе мы имеем два идентичных процесса, две идентичные ВМ на обоих ESX'ах. Теперь ВМ на исходном хосте убивается, по сети идет оповещение, что машина с этим MAC адресом доступна уже в другом месте. Все.
Если на каком то этапе идет сбой - то ВМ просто не убивается на исходном хосте.
Мне ни разу не приходилось даже слышать о падении ВМ из за VMotion - максимум сам процесс миграции закончится неудачей, значит ВМ как работала, так и будет работать.
АГА.Еще у ХА есть такая бомбовая функция ЕСЛИ машина на винде зависает или у нее БСОД ну или короче она не отвечает то если включена ХА то ЕСХ ее перезагрузит!!!
EVC — encahced vMotion compatibility — если у вас разные процессоры в серверах ESXi или разное количество ядер, то процесс миграции виртуальной машины vMotion может закончиться неудачей. Такие серверы добавить в кластер HA с ВЫключенной EVC не получится. EVC приводит серверы к общему знаменателю, чтобы они могли работать в кластере и обеспечивать отказоустойчивость. EVC в основном смотрит на процессор, понижая функциональность всех процессоров до самого слабого в кластере.
Включил обратно хост 106, но виртуальные машины остались на 115. Чтобы они вернулись обратно нужно делать миграцию vMotion руками . Чтобы они вернулись автоматически требуется DRS.
АГААА.если ХА включен то вируалка то поднимется на другом ЕСХи НО!!! чтоб если тот неисправный хост включится обратно и виртуалка перенеслась обратно туда нужно врубать ДРС!!!!
что же такое ДРС?
http://itsave.ru/vmware-ha-cluster/ вот тут еще годная статья о ХА
Так тут еще есть
Если у Вас одна линейка CPU с одинаковыми инструкциями на всех хостах, то проблем нет. А вот если разные, то тут будут проблемы. При миграции ВМ мастер сразу выдаст предупреждение на несовпадение масок CPU. Это можно обойти при условии, что CPU находятся близко друг к другу по функциям и инструкциям.
Способ первый.
Официально поддерживаемый VMware — EVC (Enhanced VMotion Compatibility). Суть технологии в том, что EVC автоматически настраивает кластер для совместимости процессоров разных поколений. В разрезе совместимость достигается тем, что на хостах где CPU более новые с новыми инструкциями, отключаются (если быть точным и более правильно, то просто не используются) данные инструкции. Скажем, если есть два хоста с CPU Intel Xeon 54XX и Intel Xeon 55XX, при выборе правильного режима EVC, на хосте с CPU Intel Xeon 55XX не используются инструкции, которых нет в Intel Xeon 54XX. В данном примере просто в кластере ВМ не будут использовать инструкции SSE 4.2.
Основной плюсы EVC то что применяется сразу ко всему кластеру, т.е на все хосты при активации. Недостаток в том, что EVC должны поддерживать сами CPU. Если CPU не поддерживает EVC, тогда смотрим чуть ниже. Плюс ко всему если у вас в кластере были хосты с ВМ в которых идут операции с поддержкой неиспользуемых функций CPU, то их придется переносить в другой кластер.
http://cloudgeek.me/2010/03/vmotion-guide/ вот тут эта статья
http://itsave.ru/vmware-data-protection/ вот тут про дата протекшн(это бекапирование ВМов)
ТАКЖЕ ЕСТЬ СТАТЬЯ ПРО ВМВАРЕ конвертер!!!!ЕЕЕЕ
кстати функционал у него бохатый:
Функционал VMware vCenter Converter Standalone:
НУ КАРОЧЕ РЕКОМЕНДОВАНО ВСЕ ТАКИ ОСТАНОВИТЬ СЕРВЕР и не делать конвертацию в рабочем режиме так как скорее всего получишь ХУЙ
а делать по хорошему нужно вот так
Порядок переноса следующий:
The differences by VMware VMotion and VMware Storage VMotion (SVMotion) and their benefits.
With VMotion, VM guests are able to move from one ESX Server to another with no downtime for the users. What is required is a shared SAN storage system between the ESX Servers and a VMotion license.
Storage VMotion (or SVMotion) is similar to VMotion in the sense that it moves VM guests without any downtime. However, what SVMotion also offers is the capability to move the storage for that guest at the same time that it moves the guest. Thus, you could move a VM guest from one ESX server’s local storage to another ESX server’s local storage with no downtime for the end users of that VM guest.
ПОЛУЧАЕТСЯ свМоушн ЭТО КАК вМоушн только без системы хранилища.Получется обычный вМоушн использует только систему хранилища для того чтоб перетащить.
А свМоушн я так понимаю МОЖЕТ НЕ ИСПОЛЬЗОВАТЬСЯ СИСТЕМУ ХРАНИЛИЩА А ПЕРЕТЯГИВАЕТ ВМ СРАЗУ НА ЛОКАЛЬНЫЙ ДИСК ДРУГОГО ЕСХи ЕСЛИ ТАМ ЕСТЬ МЕСТО!!!
http://www.vladan.fr/vmotion-vmware/ - вот тут вроде ничего статья,годная
The VMDK disk files laying on local storage are moved from one host to another without the need of shared storage. The virtual machine moves from one physical host to another without downtime.
есть еще енхансед вмоушн!
вот он и не использует хранилище
Что такое VMWare DRS
DRS - это распределенный планировщик ресурсов.он управляет КЛАСТЕРАМИ (а не ЕСХ нодами)
на видео просят чтоб был включен вМоушн
когда мы делаем павер он виртуалка ДРС решает куда на какой кластер ее воткнуть
ДРС также может заниматься павер менеджментом и вырубать а также врубать такчи по надобности экономя електроенергию
без вМоушн ДРС только будет решать где будет включена виртуалка но потом переносить и перемещать ее не будет
ну и ДРС конечно как и все остальное требует ДАТАСТОРА
ссука
https://www.youtube.com/watch?v=US0bGHtiISc
вот здесь видос когда есть 4 виртуалки под виндой.их нагружают на 100 % вернее их процы.они все стоят на одном ЕСХи а их есть 2.ну и потом врубают ДРС и делают все чики пики
кароче сначала выставили ДРС на мануал
типа ниче автоматом не делать
потом загрузили
потом посмотрели на чарт загрузки(дрс ресоурс дистрибьющн и там можно посмотреть не только по процу загрузку но и по памяти)
ну типа загружено.НО дрс не работает потому что мануал(хотя и включено)
потом идем на вкладку ДРС и запускаем ЕЕ
в режиме мануал ДРС дает рекомандации.можно нажать кнопку и она сделает и выполнит свои рекомендации
или же можно вручную это сделать самому
ДРС делает рекомендации или же передвигает машины ЕСЛИ ЕСТЬ ПЕРЕКОС ПО ПАМЯТИ ИЛИ ПО ЦПУ или то и другое вместе
также мы можем сделать ДРС полостью в автомате НО отдельным виртуалкам приказать этому не подчиняться и не переноситься
Я ПОНЯЛ.вМоушн в основном используется для ДРС!!!!вернее ДРС его юзает!!!для балансировки нагрузки!!!
все таки еще по ХА.я понимаю что он делает но как это делается я все такие не понимаю
понимаю что при вырубе компа те виртуалки что были на нем поднимаются на другом.понимаю что они где то бекапятся.понимаю что нужно место для них на новых ЕСХ хостах в кластере.а вот как это работает все таки не понима.
https://www.youtube.com/watch?v=T4DJSYfFCII буду счас смотреть вот это видео
все таки из этого виедо
ХА только на словах - на самом деле задержка будет потому как нужно время на включение(паверон) ВМки
все таки нужно датасторедж и никак иначе
ХА следит не только за сервером но и за ВМкам если они выпадают в БСОД или че то другое
серваки должны быть со статич айпи
серваки с ХА должны быть в одном кластере и у них должно быть включено ХА
ХА может быть с ДРС так и без
я так понимаю с ДРС реально будет больша ХА
в клстере есть главный сервак-FDMS он выбирается голосованием.он слушает все хертбиты мониторит ВМки а также все ЕСХ хосты
Теперь.когда включает ХА(пока без ДРС)
нужно заенаблить хеартбит.это понятно.если будем менять железо или просто останавливать машину нужно эту галочку снимать
ПОТОМ - вот та опция про которую я писал - Адмишн контрол - типа включать ли виртуалку когда на ЕСХ мало ресурсов для поддержки ХА(те отказало 2 вирт а у ЕСХ на который идет ХА ресурсы для поддержки одной).
Так вот желательно все таки НЕВКЛЮЧАТЬ эвиртуалки.Так как может весь хост нахуй леч
И третье поле в меню VshpereHA - это сколько ресурсов нужно резервировать
так вот:рекомендуют включить ресурсы в процентах и минимум по 25% резервировать
(памяти и проца)
там есть первая опция - это просто типа резервировать под один хост - типа ЕСХ сам расчитает сколько это один хост.бред.третья опция это типа есть фейловер хост и туда в случае чего будет подниматься ХА
https://www.youtube.com/watch?v=IvhwewjmnoM теперь тут смотрю фалт толеранс
АГА!фолт толеранс предоставляет ХА БЕЗ!!! даунтайма!!! (в ХА даунтайм на включение машины)
ПОСТОЯННО ДЕЛАЕТ ТЕНЕВУЮ КОПИЮ ВМки и потом врубает если что.делает это с помощю ВМВАРЕ вЛок
ТОЛЬКО ОДНО ОТЛИЧИЕ!!!ТОЛЬКО ОДНО!!! в ХА есть задержка пока машина загрузится в ФТ нет никаких задержек!!!
ФТ не для всего кластера а я так понимаю им помечаются особенные машины важность работы которых важна
Диск виртуалки висит на шаред сторадже и не двигается при ФТ
только память
НУЖНО 3!!! ГИГАБИТНЫХ ИНТЕРФЕЙСА!!!
НУЖЕН ВКЛЮЧЕННЫЙ ХА КЛАСТЕР И ОТДЕЛЬНЫЙ(из 3х допустим) интерфейсов для ФТ-логирования и вмоушн
был ESX и ESXi остался только ESXi у ЕСХ была встроенная констол.ЕСХи нужно
управлять только через вСфера
вСфера это клиент который может коннектится как к отдельному ЕСХи так и с вЦентр
вЦентр это сервак(устанавливается только на виндовс помоему) куда все серваки ЕСХи подконнекчены и оттуда можно переонсить виртуалки(в работающем состоянии) - это вМоушн
или даже их ХДД те переносим работающую виртуалку с работающим ХДД на другой ЕСХи - это всМоушн
так же был ВМВАРе -сервер но его уже нет.вернее есть и даже доступен на скачивание но его по факту не выпускают так как есть Фри ЕСХи (я так понимаю он отличается там что не тулится в вСферу и его админиить можно только отдельпо заходя на него с помощю вЦентр)
инВижн - это воркстейщн только для Мак
вЦентр - ставится только на виндоус сервере(2008 минимум помоему)
есть жеж вЦентр Виртуал Аплаенс - это для линуха(это я так понимаю уже настроеная виртуалка,просто ее запускаем,коннектимся на вебморду,подстраиваем немного а потом уже вСфер клиентом лезем на нее и туда коннектим ЕСХи да и делов)
https://www.youtube.com/watch?v=YSSQnAoiFtg вот тут видео про это все
В вЦентре все просто.устанавливаем его образ на машину
потом коннектимся в него вСферой.Потом создаем новый датацентр.потом добавляем ЕСХи вписываем логи пароль и айпишник(можно ДНС)
кароче после того как добавили можем там подключать НФС или по АЙСКАЗИ винты.по поводу сети можем подключать сети с вланИД также там есть вСвитч кароче вмы могут между собой общаться а также внутри ЕСХ сервера может быть типа виртуальный вСвич и там могут быть несколько виртуалок общаться между собой или быть разбиты на группы и изолированы с помощю вланов
что нового в 6 вСфере:https://www.youtube.com/watch?v=0B3hDris8CM
тут про НУМА и про НУМА в ЕСХи https://habrahabr.ru/post/122535/
С помощью компонента vSphere Fault Tolerance (FT) поддерживайте непрерывную доступность приложений (на четырех виртуальных процессорах) в случае сбоев на сервере. Она создает фоновый экземпляр работающей виртуальной машины, в точности соответствующий основной ВМ. При отключении питания функция vSphere FT автоматически инициирует аварийное переключение. Будет создана и запущена резервная виртуальная машина, что обеспечит непрерывную защиту приложения. Данная технология совместима со всеми типами общих систем хранения данных и всеми операционными системами, поддерживаемыми платформой vSphere.
вообще тут про ХА http://itband.ru/2010/06/vsphere-ha-cluste/
а тут типа глубокое ХА http://itband.ru/2009/12/vmware-slots/
достаточно легко если что
тут про разницу между фолт толеранс и хай авиабилити
http://searchvmware.techtarget.com/essentialguide/Avoiding-downtime-with-VMware-Fault-Tolerance-and-High-Availability
я так понимаю что проблема у ФТ в том чтоб в виртуалках которые в ФТ им выделяют только один виртуальный процессор
Так.для ХА нужно правильно расчитівать Failover Capacity - єто смогут ли остальніе ЕСХи серваки в кластере,вернее будет ли у них место на винтах,процессорі и память ,она расчитівается по спцец формуле.Потом опять же должно біть хранилище с гигабитной сетью(в самом плохом случае єто НФС)
ТЕПЕРЬ ЧТО ТАКОЕ вМОУШН(я знаю что єто такое НО БЛЯТЬ НАХУЯ ОНО НУЖНО!!0) и что такое ДРС
http://www.vm4.ru/2007/10/vmotion.html - вот тут детально описание вМОУШН
вообще ОН СУЩЕСТВУЕТ ТОЛЬКО ДЛЯ ПЕРЕНОСА ВМ НА ДРУГОЙ ЕСХи без остановки работы!причем перенос идет так:
Тыкаем правой кнопкой в ВМ, выбираем Migrate. Если ВМ включена - этот пункт и запустит VMotion. Выбираем хост, на который хотим смигрировать. Процесс начинается. Если все условия выполнены - скорее всего :) он заканчивается нормально.
По поводу того, что из себя представляет сам процесс, и что идет через сеть VMotion -
Как только мы запускаем миграцию, память нашей ВМ блокируется на запись. ВМ продолжает работать, но все изменения в ее оперативке пишутся "рядом" с заблокированным массивом.
Теперь эта память передается на другой ESX. Именно через интерфейс vmkernel, который мы задействуем под VMotion.
Как только вся передалась - ВМ блокируется полностью - и на второй ESX передается область памяти с изменениями. Т.к. он почти наверняка будет небольшой - время в течении которого ВМ полностью блокируется также невелико. Весьма невелико.
На этом этапе мы имеем два идентичных процесса, две идентичные ВМ на обоих ESX'ах. Теперь ВМ на исходном хосте убивается, по сети идет оповещение, что машина с этим MAC адресом доступна уже в другом месте. Все.
Если на каком то этапе идет сбой - то ВМ просто не убивается на исходном хосте.
Мне ни разу не приходилось даже слышать о падении ВМ из за VMotion - максимум сам процесс миграции закончится неудачей, значит ВМ как работала, так и будет работать.
АГА.Еще у ХА есть такая бомбовая функция ЕСЛИ машина на винде зависает или у нее БСОД ну или короче она не отвечает то если включена ХА то ЕСХ ее перезагрузит!!!
EVC — encahced vMotion compatibility — если у вас разные процессоры в серверах ESXi или разное количество ядер, то процесс миграции виртуальной машины vMotion может закончиться неудачей. Такие серверы добавить в кластер HA с ВЫключенной EVC не получится. EVC приводит серверы к общему знаменателю, чтобы они могли работать в кластере и обеспечивать отказоустойчивость. EVC в основном смотрит на процессор, понижая функциональность всех процессоров до самого слабого в кластере.
Включил обратно хост 106, но виртуальные машины остались на 115. Чтобы они вернулись обратно нужно делать миграцию vMotion руками . Чтобы они вернулись автоматически требуется DRS.
АГААА.если ХА включен то вируалка то поднимется на другом ЕСХи НО!!! чтоб если тот неисправный хост включится обратно и виртуалка перенеслась обратно туда нужно врубать ДРС!!!!
что же такое ДРС?
http://itsave.ru/vmware-ha-cluster/ вот тут еще годная статья о ХА
Так тут еще есть
Если у Вас одна линейка CPU с одинаковыми инструкциями на всех хостах, то проблем нет. А вот если разные, то тут будут проблемы. При миграции ВМ мастер сразу выдаст предупреждение на несовпадение масок CPU. Это можно обойти при условии, что CPU находятся близко друг к другу по функциям и инструкциям.
Способ первый.
Официально поддерживаемый VMware — EVC (Enhanced VMotion Compatibility). Суть технологии в том, что EVC автоматически настраивает кластер для совместимости процессоров разных поколений. В разрезе совместимость достигается тем, что на хостах где CPU более новые с новыми инструкциями, отключаются (если быть точным и более правильно, то просто не используются) данные инструкции. Скажем, если есть два хоста с CPU Intel Xeon 54XX и Intel Xeon 55XX, при выборе правильного режима EVC, на хосте с CPU Intel Xeon 55XX не используются инструкции, которых нет в Intel Xeon 54XX. В данном примере просто в кластере ВМ не будут использовать инструкции SSE 4.2.
Основной плюсы EVC то что применяется сразу ко всему кластеру, т.е на все хосты при активации. Недостаток в том, что EVC должны поддерживать сами CPU. Если CPU не поддерживает EVC, тогда смотрим чуть ниже. Плюс ко всему если у вас в кластере были хосты с ВМ в которых идут операции с поддержкой неиспользуемых функций CPU, то их придется переносить в другой кластер.
http://cloudgeek.me/2010/03/vmotion-guide/ вот тут эта статья
http://itsave.ru/vmware-data-protection/ вот тут про дата протекшн(это бекапирование ВМов)
ТАКЖЕ ЕСТЬ СТАТЬЯ ПРО ВМВАРЕ конвертер!!!!ЕЕЕЕ
кстати функционал у него бохатый:
Функционал VMware vCenter Converter Standalone:
- Конвертация операционной системы установленной на физическом сервере в виртуальную машину для ESXi
- Конвертация виртуальной машины из ESXi в виртуальную машину для ESXi последней версии
- Конвертация файла бэкапа Data Protection в виртуальную машину для ESXi
- Конвертация виртуальных машин из Hyper-V в виртуальную машину для ESXi
- Конвертация резервной копии Acronis (.tib) в виртуальную машину для ESXi
- Конвертация из резервной копии Sumantec (.sv2i) в виртуальную машину для ESXi
- и другие форматы в виртуальную машину для ESX
НУ КАРОЧЕ РЕКОМЕНДОВАНО ВСЕ ТАКИ ОСТАНОВИТЬ СЕРВЕР и не делать конвертацию в рабочем режиме так как скорее всего получишь ХУЙ
а делать по хорошему нужно вот так
Конвертация через Acronis Boot CD
Создавать новые виртуальные машины из работающих операционных систем
мне кажется не самой лучшей идеей, можно несколько часов ждать окончания
переноса и на 99% увидеть FAILED.
Поэтому более надежный способ — это сначала сделать резервную копию
через загрузочный диск Acronis, а затем из него уже сконвертировать
виртуальную машину. Образ Acronis Boot CD можно скачать тут.Порядок переноса следующий:
- Останавливаете сервер, который нужно перенести.
- Загружаете этот сервер с Acronis Boot CD
- Делаете актуальную резервную копию, получаете файл .tib
- Запускаете VMware Converter и скармливаете ему файл .tib
- В остальном все совпадает с переносом обычным методом
The differences by VMware VMotion and VMware Storage VMotion (SVMotion) and their benefits.
With VMotion, VM guests are able to move from one ESX Server to another with no downtime for the users. What is required is a shared SAN storage system between the ESX Servers and a VMotion license.
Storage VMotion (or SVMotion) is similar to VMotion in the sense that it moves VM guests without any downtime. However, what SVMotion also offers is the capability to move the storage for that guest at the same time that it moves the guest. Thus, you could move a VM guest from one ESX server’s local storage to another ESX server’s local storage with no downtime for the end users of that VM guest.
ПОЛУЧАЕТСЯ свМоушн ЭТО КАК вМоушн только без системы хранилища.Получется обычный вМоушн использует только систему хранилища для того чтоб перетащить.
А свМоушн я так понимаю МОЖЕТ НЕ ИСПОЛЬЗОВАТЬСЯ СИСТЕМУ ХРАНИЛИЩА А ПЕРЕТЯГИВАЕТ ВМ СРАЗУ НА ЛОКАЛЬНЫЙ ДИСК ДРУГОГО ЕСХи ЕСЛИ ТАМ ЕСТЬ МЕСТО!!!
http://www.vladan.fr/vmotion-vmware/ - вот тут вроде ничего статья,годная
Enhanced vMotion
Has been introduced in vSphere 5.1 and it’s combining the vMotion and Storage vmotion, but it’s process which can be invoked only manually through the new vSphere web client. The new vSphere 5.1 feature has been detailed (with screenshot) in my post here – VMware Enhanced vMotion in vSphere 5.1.The VMDK disk files laying on local storage are moved from one host to another without the need of shared storage. The virtual machine moves from one physical host to another without downtime.
есть еще енхансед вмоушн!
вот он и не использует хранилище
Что такое VMWare DRS
DRS - это распределенный планировщик ресурсов.он управляет КЛАСТЕРАМИ (а не ЕСХ нодами)
на видео просят чтоб был включен вМоушн
когда мы делаем павер он виртуалка ДРС решает куда на какой кластер ее воткнуть
ДРС также может заниматься павер менеджментом и вырубать а также врубать такчи по надобности экономя електроенергию
без вМоушн ДРС только будет решать где будет включена виртуалка но потом переносить и перемещать ее не будет
ну и ДРС конечно как и все остальное требует ДАТАСТОРА
ссука
https://www.youtube.com/watch?v=US0bGHtiISc
вот здесь видос когда есть 4 виртуалки под виндой.их нагружают на 100 % вернее их процы.они все стоят на одном ЕСХи а их есть 2.ну и потом врубают ДРС и делают все чики пики
кароче сначала выставили ДРС на мануал
типа ниче автоматом не делать
потом загрузили
потом посмотрели на чарт загрузки(дрс ресоурс дистрибьющн и там можно посмотреть не только по процу загрузку но и по памяти)
ну типа загружено.НО дрс не работает потому что мануал(хотя и включено)
потом идем на вкладку ДРС и запускаем ЕЕ
в режиме мануал ДРС дает рекомандации.можно нажать кнопку и она сделает и выполнит свои рекомендации
или же можно вручную это сделать самому
ДРС делает рекомендации или же передвигает машины ЕСЛИ ЕСТЬ ПЕРЕКОС ПО ПАМЯТИ ИЛИ ПО ЦПУ или то и другое вместе
также мы можем сделать ДРС полостью в автомате НО отдельным виртуалкам приказать этому не подчиняться и не переноситься
Я ПОНЯЛ.вМоушн в основном используется для ДРС!!!!вернее ДРС его юзает!!!для балансировки нагрузки!!!
все таки еще по ХА.я понимаю что он делает но как это делается я все такие не понимаю
понимаю что при вырубе компа те виртуалки что были на нем поднимаются на другом.понимаю что они где то бекапятся.понимаю что нужно место для них на новых ЕСХ хостах в кластере.а вот как это работает все таки не понима.
https://www.youtube.com/watch?v=T4DJSYfFCII буду счас смотреть вот это видео
все таки из этого виедо
ХА только на словах - на самом деле задержка будет потому как нужно время на включение(паверон) ВМки
все таки нужно датасторедж и никак иначе
ХА следит не только за сервером но и за ВМкам если они выпадают в БСОД или че то другое
серваки должны быть со статич айпи
серваки с ХА должны быть в одном кластере и у них должно быть включено ХА
ХА может быть с ДРС так и без
я так понимаю с ДРС реально будет больша ХА
в клстере есть главный сервак-FDMS он выбирается голосованием.он слушает все хертбиты мониторит ВМки а также все ЕСХ хосты
Теперь.когда включает ХА(пока без ДРС)
нужно заенаблить хеартбит.это понятно.если будем менять железо или просто останавливать машину нужно эту галочку снимать
ПОТОМ - вот та опция про которую я писал - Адмишн контрол - типа включать ли виртуалку когда на ЕСХ мало ресурсов для поддержки ХА(те отказало 2 вирт а у ЕСХ на который идет ХА ресурсы для поддержки одной).
Так вот желательно все таки НЕВКЛЮЧАТЬ эвиртуалки.Так как может весь хост нахуй леч
И третье поле в меню VshpereHA - это сколько ресурсов нужно резервировать
так вот:рекомендуют включить ресурсы в процентах и минимум по 25% резервировать
(памяти и проца)
там есть первая опция - это просто типа резервировать под один хост - типа ЕСХ сам расчитает сколько это один хост.бред.третья опция это типа есть фейловер хост и туда в случае чего будет подниматься ХА
https://www.youtube.com/watch?v=IvhwewjmnoM теперь тут смотрю фалт толеранс
АГА!фолт толеранс предоставляет ХА БЕЗ!!! даунтайма!!! (в ХА даунтайм на включение машины)
ПОСТОЯННО ДЕЛАЕТ ТЕНЕВУЮ КОПИЮ ВМки и потом врубает если что.делает это с помощю ВМВАРЕ вЛок
ТОЛЬКО ОДНО ОТЛИЧИЕ!!!ТОЛЬКО ОДНО!!! в ХА есть задержка пока машина загрузится в ФТ нет никаких задержек!!!
ФТ не для всего кластера а я так понимаю им помечаются особенные машины важность работы которых важна
Диск виртуалки висит на шаред сторадже и не двигается при ФТ
только память
НУЖНО 3!!! ГИГАБИТНЫХ ИНТЕРФЕЙСА!!!
НУЖЕН ВКЛЮЧЕННЫЙ ХА КЛАСТЕР И ОТДЕЛЬНЫЙ(из 3х допустим) интерфейсов для ФТ-логирования и вмоушн
суббота, 9 июля 2016 г.
Consul что это такое,как он работает и с чем его едят.
Статью пишу чисто для себя так что если кто чем недоволен то это его личные проблемы.
Итак:что такое Consul(для краткости буду писать КО)
первая функция:КО - это сервис обнаружения служб (если у вас много виртуалок или докеров и они ездят
по датацентрам то вам нужно же знать куда и что переехало и на каком порту и ИП это висит,те при переезде новый контейнер докер узнает куда обращаться к БД,или например сменился мастер PgSQL и контейнеры хотят узнать где новый мастерчтоб туда писать или еще что то),
собственно говоря из этого вытекает что для того чтоб знать где эти службы нужно где то хранить данные об этих службах(в самом простом понимании это порт и айпишник),
и тут у нас выплывает вторая функция :
КО - это БД (хранилище) в виде key:value,
третья функция: КО - он делает хелс чеки(health check)(в самом простом понимании можно на хост\порт отправить хттп\днс запрос(например при помощи curl) или какой нить telnet и получить ответ что у него все OK и он работает),и если например сервис не работает то он не отдает о нем данные и отдаст о другом или вообще не отдаст и скажет что все плохо,
четвертая функция: - он распределенный,балансирует свои серваки,может общаться между датацентрами,вообщем high aviability если у нас несколько серваков(от 3х,ниже будет написано...),
ну и понятно из этого что серваки синхронизируют инфу между собой,НО не так просто синхронизирую а по протоколу gossip что в переводе с английского - слухи.На википедии есть целая статья про этот вид протокола общения,в кратце его еще называют протоколом эпидемии,кароче рандомно серваки связываются между собой и отдают инфу кто где и так,через определенные промежутки времени,прям как распостраняются слухи)))
Про Gossip Protocol(кратко госсип):
Из пула выбираются соседи,они меняются инфой,один из них меняет стейт(он получил слух или же заразился эпидемией,как хотите...) ну и потом пошло поехало.Тот который заразился говорит со своим соседом и т д.
Затраты на протокол при этом очень незначительны,на вики написано что в связи с репликацией существует неявная избыточность этой информации.ну хз.может и так.
Собственно говоря если вникнуть в госсип поглубже то два агента первый раз когда встречаются проверяют у себя кэш на наличие какого нить стринга. У одного есть А а у другого Б потом они оба расходятся в кэшэ со стрнгами А и Б. Потом соответственно с информацией что у 1 его есть АБ и у второго есть АБ 1 и 2 агент уже не хотят встречаться с друг другом в ближайщее время потому что слухи знают(у обоих А и Б) и будут встречаться уже с 3 и 4 например.и понеслась...)))...ну и соответственно к каждому стрингу крепится таймстамп так как у агентов могут быть 2 одинаковых слуха и нужно узнать какой старше.
Архитекрура:
Консул агент - это прога которая может быть и клиентом и сервером.
ТЕ Есть только консул агент и ничего больше.В разных ролях.Один бинарник.Все.
Клиент режим агента -- tсли агент в режиме клиента то он просто адресует RPC запросы к серваку получает ответы в виде JSON обьека или ДНС ответа да и делов.
Серверный режим агента -- он может поднимать http или же dns сервак для ответов клиентам а также производить health check и еще плюс к этому находиться в кластере серверов менять свои роли общаться с другими серваками
Госсип протокол:
В каждом датацентре где живет консул есть ЛАН Госсип - это пул всех серваков и клиентов ДЦ.Это сделано для того чтоб клиенты могли делать автоматик дискавер и быстро находить соседей вледствии этого соответственно серваки и наоборот чтоб серваки могли быстро узнавать о клиенте.
С помощю ЛАН госсип быстро происходит распостранение информации.Например о сбое клиента.И эта инфа расшаривается самими клиентами а не только серваками те. когда слухи дойдут до серваком об этом уже могут знать многие клиенты в следствии того чтоб они пытались достучаться до своих соседей или как то достучались и поняли что там что то не так.
Опять же в этом лан будет идет быстрая широковещался на предмет выбора лидера(главного сервака в пуле серверов КО или для быстрой передачи каких либо событий,вообщем это быстро)
В связи с этим можно сказать что КО обеспечивает распределенную систему обнаружения сбоев(как по сервакам так и по клиентам)
ВАН Госсип:
В ВАН пуле участвуют только сервера.Если сервак является членом этого пула то он может посылать запросы как сервакам в своем датацентре так и в другие датацентры.Опять же система обнаружения сбоев позволяет поддерживать датацентр за счет удаленного одного или нескольких датацентров.
По серверам: они едут все на плоту(RAFT протокол) ну типа и у них есть лидер.и серваки синхронятся опять же друг с другом по госсипу и узнают кто лидер и берут всю инфу у лидера(ну и дают конечно же).ТЕ среди серваков лидер знает все что можно!типа главный сервак со всей возможной инфой.
Теперь по РАФТ протоколу:
Рафт протокол базируется на протоколе Паксос.Но он легче и имеет меньше состояний.
Главный компонент протокола - запись в логе.Проблема целостности журнала решается реплицированием лога и если при этом все серваки считают что этот записи в этом логе валидны и расположены в правильной последовательности
Логи ведутся в соответствии с ФСМ или Финит Стейт Машин.Те у логов есть какие то конечные состояния.И есть переходы между ними.Те есть последовательность в журнале.и когда пишется в журнал то позволяется в логе состояние перехода но в итоге все кто получили этот лог должны прийти в тоже состояние в котором и мастер
Набор пиров - это набор сервако в в ЛАН пуле которые разделяют репликацию главного лога
Кворум - если серверов больше 3х то они выбирают лидера кворумом по формуле
Завершенная запись - я так понимаю это запись в логе о которой есть инфа что она уже храниться на всех членах пули и только тогда она отдается клиентам.
Лидер - В любой момент времени,пиры выбирает один узел, чтобы он был лидером. Лидер отвечает за записьновых записей,раздачу членам пула своего лога чтоб они его реплицировали
Ноды серверного пула всегда в 3х состояниях:
последователь,кандидат в лидеры и лидер.Каждая нода сначала последователь и в этом состоянии она толкьо получает лог файл и может голосовать,если она не получает от лидера инфы какое то время то нода инициирует голосование и становится кандидатом.Если ее выбрали кворумом она становится лидером и раздает свой лог последователям.Как то так.
Вот так и работает протокол РАФТ.
Если у нас 3 КО то они устойчивы к падению одного ,если 5 то к падению 2х серваков.
Серваки деляться на: повторитель,кандидат в лидеры и лидер.
ЗАПИСЫВАЕТ В кей:велью ТОЛЬКО ЛИДЕР
Сеть:для того чтоб все быстрее работало консул вычисляет вес пути и типа общается с тем кто ближе,по возможности.Это вкратце
Сессия:для получения КВ делаются сесси.
когда нода зарегилась она получила ТТЛ,ИД сессии,набор хелсчеков и стоп-паузу,
чтоб сессия стала невалидной нужно чтобы:
нода дерегистрировалась,
провалились хелсчеки,
хелсчеки ответили что все плохо,
ТТЛ сесси прошел,
И ТОГДА СЕССИЯ УНИЧТОЖИТСЯ
У каждой сесси есть айдишник.
Кароче нода делает чеки и если чеки прошли и все ок то эти чеки пишуться в сессию и при это нода получает доступ к КВ базе данных.Как то так вроде.
Когда сеанс признан недействительным по причине вышепреведенным сессия убивается.
Если вкратце то есть сессии с хелс чеками и без.Если без то это проще.
АЦЛ - с версии 0.4 есть ацл ну тут думаю не стоит даже и описания.все понятно
Анти- этнропия : набор методов чтоб все было упрядочено:
Чтоб понять анти энтропию нужно понять что есть агенты и есть каталог
Агенты САМИ проводят набор своих внутренних хелсчеков и чеков сервисов и локально апдейтят свой статус
Каталог это БД для сервис дискавери те для госсипа и там хранятся все слухи.
Каталог висит только на серверах.Инфы о хелс чеках на нем меньше чем на клиентах потому что там еще есть свои внутренние хелсчеки которые нах каталогу не нужно хранить и если че можно опросить клиента
Анти энтропия состоит в том что агенты ложат в бд инфу о своем состоянии НО НЕ ПОЛНУЮ а просто типа у нас ВСЕ ОК.и потом соответственно сервер распостраняет это инфу везде.как то так.
И еще кроме по ивентам чеки проводятся периодически и проверяется актуальность каталога
КОНТРОЛЬ КОНСУЛА!:
он контролится с помощю КЛИ:
<code>$ consul
usage: consul [--version] [--help] <command> [<args>]
Available commands are:
agent Runs a Consul agent
event Fire a new event
exec Executes a command on Consul nodes
force-leave Forces a member of the cluster to enter the "left" state
info Provides debugging information for operators
join Tell Consul agent to join cluster
keygen Generates a new encryption key
keyring Manages gossip layer encryption keys
leave Gracefully leaves the Consul cluster and shuts down
lock Execute a command holding a lock
members Lists the members of a Consul cluster
monitor Stream logs from a Consul agent
reload Triggers the agent to reload configuration files
rtt Estimates network round trip time between nodes
version Prints the Consul version
watch Watch for changes in Consul
</code>
вот такие простые команда.думаю должно быть все понятно
вот мы стартуем самую главную шнягу это консул агент.он стартует и должен присоединится к кластеру.можно вручную а можно авто-джоин сделать.как только он присоединился слух расползся и он попадает в каталоги понеслась.при этом о нем уже знают куча пиров и клиентов.
Ну и теперь наконец то про то как делать запросы:САМОЕ ВАЖНОЕ ДЛЯ ЧЕГО ОН СДЕЛАН!!!)))
можно делать по ДНС а можно по HTTP но по ДНС кроме ИП и порта хуй что получишь а по хттп можно получть больше
Вот запрос к серваку по ДНС и он отдает ИП и ПОРТ
остальное допишу завтра.устал...
Итак:что такое Consul(для краткости буду писать КО)
первая функция:КО - это сервис обнаружения служб (если у вас много виртуалок или докеров и они ездят
по датацентрам то вам нужно же знать куда и что переехало и на каком порту и ИП это висит,те при переезде новый контейнер докер узнает куда обращаться к БД,или например сменился мастер PgSQL и контейнеры хотят узнать где новый мастерчтоб туда писать или еще что то),
собственно говоря из этого вытекает что для того чтоб знать где эти службы нужно где то хранить данные об этих службах(в самом простом понимании это порт и айпишник),
и тут у нас выплывает вторая функция :
КО - это БД (хранилище) в виде key:value,
третья функция: КО - он делает хелс чеки(health check)(в самом простом понимании можно на хост\порт отправить хттп\днс запрос(например при помощи curl) или какой нить telnet и получить ответ что у него все OK и он работает),и если например сервис не работает то он не отдает о нем данные и отдаст о другом или вообще не отдаст и скажет что все плохо,
четвертая функция: - он распределенный,балансирует свои серваки,может общаться между датацентрами,вообщем high aviability если у нас несколько серваков(от 3х,ниже будет написано...),
ну и понятно из этого что серваки синхронизируют инфу между собой,НО не так просто синхронизирую а по протоколу gossip что в переводе с английского - слухи.На википедии есть целая статья про этот вид протокола общения,в кратце его еще называют протоколом эпидемии,кароче рандомно серваки связываются между собой и отдают инфу кто где и так,через определенные промежутки времени,прям как распостраняются слухи)))
Про Gossip Protocol(кратко госсип):
Из пула выбираются соседи,они меняются инфой,один из них меняет стейт(он получил слух или же заразился эпидемией,как хотите...) ну и потом пошло поехало.Тот который заразился говорит со своим соседом и т д.
Затраты на протокол при этом очень незначительны,на вики написано что в связи с репликацией существует неявная избыточность этой информации.ну хз.может и так.
Собственно говоря если вникнуть в госсип поглубже то два агента первый раз когда встречаются проверяют у себя кэш на наличие какого нить стринга. У одного есть А а у другого Б потом они оба расходятся в кэшэ со стрнгами А и Б. Потом соответственно с информацией что у 1 его есть АБ и у второго есть АБ 1 и 2 агент уже не хотят встречаться с друг другом в ближайщее время потому что слухи знают(у обоих А и Б) и будут встречаться уже с 3 и 4 например.и понеслась...)))...ну и соответственно к каждому стрингу крепится таймстамп так как у агентов могут быть 2 одинаковых слуха и нужно узнать какой старше.
Архитекрура:
Консул агент - это прога которая может быть и клиентом и сервером.
ТЕ Есть только консул агент и ничего больше.В разных ролях.Один бинарник.Все.
Клиент режим агента -- tсли агент в режиме клиента то он просто адресует RPC запросы к серваку получает ответы в виде JSON обьека или ДНС ответа да и делов.
Серверный режим агента -- он может поднимать http или же dns сервак для ответов клиентам а также производить health check и еще плюс к этому находиться в кластере серверов менять свои роли общаться с другими серваками
Госсип протокол:
В каждом датацентре где живет консул есть ЛАН Госсип - это пул всех серваков и клиентов ДЦ.Это сделано для того чтоб клиенты могли делать автоматик дискавер и быстро находить соседей вледствии этого соответственно серваки и наоборот чтоб серваки могли быстро узнавать о клиенте.
С помощю ЛАН госсип быстро происходит распостранение информации.Например о сбое клиента.И эта инфа расшаривается самими клиентами а не только серваками те. когда слухи дойдут до серваком об этом уже могут знать многие клиенты в следствии того чтоб они пытались достучаться до своих соседей или как то достучались и поняли что там что то не так.
Опять же в этом лан будет идет быстрая широковещался на предмет выбора лидера(главного сервака в пуле серверов КО или для быстрой передачи каких либо событий,вообщем это быстро)
В связи с этим можно сказать что КО обеспечивает распределенную систему обнаружения сбоев(как по сервакам так и по клиентам)
ВАН Госсип:
В ВАН пуле участвуют только сервера.Если сервак является членом этого пула то он может посылать запросы как сервакам в своем датацентре так и в другие датацентры.Опять же система обнаружения сбоев позволяет поддерживать датацентр за счет удаленного одного или нескольких датацентров.
По серверам: они едут все на плоту(RAFT протокол) ну типа и у них есть лидер.и серваки синхронятся опять же друг с другом по госсипу и узнают кто лидер и берут всю инфу у лидера(ну и дают конечно же).ТЕ среди серваков лидер знает все что можно!типа главный сервак со всей возможной инфой.
Теперь по РАФТ протоколу:
Рафт протокол базируется на протоколе Паксос.Но он легче и имеет меньше состояний.
Главный компонент протокола - запись в логе.Проблема целостности журнала решается реплицированием лога и если при этом все серваки считают что этот записи в этом логе валидны и расположены в правильной последовательности
Логи ведутся в соответствии с ФСМ или Финит Стейт Машин.Те у логов есть какие то конечные состояния.И есть переходы между ними.Те есть последовательность в журнале.и когда пишется в журнал то позволяется в логе состояние перехода но в итоге все кто получили этот лог должны прийти в тоже состояние в котором и мастер
Набор пиров - это набор сервако в в ЛАН пуле которые разделяют репликацию главного лога
Кворум - если серверов больше 3х то они выбирают лидера кворумом по формуле
(n/2)+1
Завершенная запись - я так понимаю это запись в логе о которой есть инфа что она уже храниться на всех членах пули и только тогда она отдается клиентам.
Лидер - В любой момент времени,пиры выбирает один узел, чтобы он был лидером. Лидер отвечает за записьновых записей,раздачу членам пула своего лога чтоб они его реплицировали
Ноды серверного пула всегда в 3х состояниях:
последователь,кандидат в лидеры и лидер.Каждая нода сначала последователь и в этом состоянии она толкьо получает лог файл и может голосовать,если она не получает от лидера инфы какое то время то нода инициирует голосование и становится кандидатом.Если ее выбрали кворумом она становится лидером и раздает свой лог последователям.Как то так.
Вот так и работает протокол РАФТ.
Если у нас 3 КО то они устойчивы к падению одного ,если 5 то к падению 2х серваков.
Серваки деляться на: повторитель,кандидат в лидеры и лидер.
ЗАПИСЫВАЕТ В кей:велью ТОЛЬКО ЛИДЕР
Сеть:для того чтоб все быстрее работало консул вычисляет вес пути и типа общается с тем кто ближе,по возможности.Это вкратце
Сессия:для получения КВ делаются сесси.
когда нода зарегилась она получила ТТЛ,ИД сессии,набор хелсчеков и стоп-паузу,
чтоб сессия стала невалидной нужно чтобы:
нода дерегистрировалась,
провалились хелсчеки,
хелсчеки ответили что все плохо,
ТТЛ сесси прошел,
И ТОГДА СЕССИЯ УНИЧТОЖИТСЯ
У каждой сесси есть айдишник.
Кароче нода делает чеки и если чеки прошли и все ок то эти чеки пишуться в сессию и при это нода получает доступ к КВ базе данных.Как то так вроде.
Когда сеанс признан недействительным по причине вышепреведенным сессия убивается.
Если вкратце то есть сессии с хелс чеками и без.Если без то это проще.
АЦЛ - с версии 0.4 есть ацл ну тут думаю не стоит даже и описания.все понятно
Анти- этнропия : набор методов чтоб все было упрядочено:
Чтоб понять анти энтропию нужно понять что есть агенты и есть каталог
Агенты САМИ проводят набор своих внутренних хелсчеков и чеков сервисов и локально апдейтят свой статус
Каталог это БД для сервис дискавери те для госсипа и там хранятся все слухи.
Каталог висит только на серверах.Инфы о хелс чеках на нем меньше чем на клиентах потому что там еще есть свои внутренние хелсчеки которые нах каталогу не нужно хранить и если че можно опросить клиента
Анти энтропия состоит в том что агенты ложат в бд инфу о своем состоянии НО НЕ ПОЛНУЮ а просто типа у нас ВСЕ ОК.и потом соответственно сервер распостраняет это инфу везде.как то так.
И еще кроме по ивентам чеки проводятся периодически и проверяется актуальность каталога
КОНТРОЛЬ КОНСУЛА!:
он контролится с помощю КЛИ:
<code>$ consul
usage: consul [--version] [--help] <command> [<args>]
Available commands are:
agent Runs a Consul agent
event Fire a new event
exec Executes a command on Consul nodes
force-leave Forces a member of the cluster to enter the "left" state
info Provides debugging information for operators
join Tell Consul agent to join cluster
keygen Generates a new encryption key
keyring Manages gossip layer encryption keys
leave Gracefully leaves the Consul cluster and shuts down
lock Execute a command holding a lock
members Lists the members of a Consul cluster
monitor Stream logs from a Consul agent
reload Triggers the agent to reload configuration files
rtt Estimates network round trip time between nodes
version Prints the Consul version
watch Watch for changes in Consul
</code>
вот такие простые команда.думаю должно быть все понятно
consul agent -data-dir=/tmp/consul
==> Starting Consul agent...
==> Starting Consul agent RPC...
==> Consul agent running!
Node name: 'Armons-MacBook-Air'
Datacenter: 'dc1'
Server: false (bootstrap: false)
Client Addr: 127.0.0.1 (HTTP: 8500, DNS: 8600, RPC: 8400)
Cluster Addr: 192.168.1.43 (LAN: 8301, WAN: 8302)
Atlas: (Infrastructure: 'hashicorp/test' Join: true)
==> Log data will now stream in as it occurs:
[INFO] serf: EventMemberJoin: Armons-MacBook-Air.local 192.168.1.43
вот мы стартуем самую главную шнягу это консул агент.он стартует и должен присоединится к кластеру.можно вручную а можно авто-джоин сделать.как только он присоединился слух расползся и он попадает в каталоги понеслась.при этом о нем уже знают куча пиров и клиентов.
Ну и теперь наконец то про то как делать запросы:САМОЕ ВАЖНОЕ ДЛЯ ЧЕГО ОН СДЕЛАН!!!)))
можно делать по ДНС а можно по HTTP но по ДНС кроме ИП и порта хуй что получишь а по хттп можно получть больше
$ dig @127.0.0.1 -p 8600 consul.service.consul SRV
; <<>> DiG 9.8.3-P1 <<>> @127.0.0.1 -p 8600 consul.service.consul ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50483
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;consul.service.consul. IN SRV
;; ANSWER SECTION:
consul.service.consul. 0 IN SRV 1 1 8300 foobar.node.dc1.consul.
;; ADDITIONAL SECTION:
foobar.node.dc1.consul. 0 IN A 10.1.10.12 Вот запрос к серваку по ДНС и он отдает ИП и ПОРТ
остальное допишу завтра.устал...
Подписаться на:
Сообщения (Atom)