между площадками негарантированный гигабит
первоначально создаются два LVM-тома и дальше обычная drbd-синхронизация. Поскольку данные с обеих сторон изначально одинаковые (нули для чистого диска или клон одного и того же шаблона) — синхронизация проходит за несколько минут для диска в 10Гб, нагрузки ни на диски ни на канал при этом не создается.
Так же на будущее опробована начальная синхронизация сразу методом записи правильных метаданных. Поскольку начальное содержимое дисков одинаковое — это допускается и занимает несколько секунд уже для любых объёмов. Пока не применяется, т.к. первый способ проще и никаких неудобств на данный момент не доставляет.
В теории — если операции записи идут одна за другой (т.е. рандомно, но в один поток) — 50% вполне хорошо, больше и не будет просто из устройства ceph (клиент передает данные на первый сервер, первый сервер пишет у себя и синхронно передает оставшимся ко количеству реплик, об успешной записи клиент получает подтверждение когда все реплики записаны).
Если писать параллельно — много писателей, много хранилищь, то думаю выжать можно много — добавляйте дисков (серверов) и нагрузка будет распределяться и суммарная скорость будет увеличиваться почти кратно количеству серверов — мониторы в работе не участвуют, клиенты сами распределяют нагрузку по всем серверам.
Это было несколько лет назад, так что в деталях могу ошибаться и ситуация могла поменяться.
Он у меня ломался два раза.
1. Один раз совсем, когда я его мучал в режиме: подключить ноду/отключить ноду/подключить ноду/отключить ноду несколько раз подряд прямо в процессе репликации, при этом что-то делал с rbd-образами и включал/выключал мониторы. В какой-то момент часть данных сказала «я не знаю где нахожусь, откуда реплицироваться и т.п.».
Второй раз уже в обычном режиме, сломалась клиентская часть — просто работал с rbd-образами: создавал, удалял, блокировал, разблокировал и пришел к такому состоянию когда с конкретно этим образом сделать уже ничего нельзя — он подвис на хост-системах где монтировался. Т.е. можно например подмонтировать его на другой ноде, но не на первой. Первую надо ребутить целиком.
Был опыт как раз с их failover IP, для начала очень удобная штука. Пару раз даже приходилось переключать.
Про дата-центры я тоже думал что они не зависят друг от друга и поддержка так говорила.
Потом в один прекрасный день (этим летом) у них сломалась центральная железка и интернет упал в обоих «независимых» дата-центрах, собственно поэтому дата-центры теперь вообще от разных компаний и в разных городах.
Сейчас переключение BGP происходит похожим образом: одна сеть анонсируется одновременно в двух дата-центрах. Если один дата-центр падает/выключается — весь трафик направляется в оставшийся. Входящий трафик, пришедший «не в тот» дата-центр маршрутизируется в «правильный» уже по внутренней сети, обратный ответ уходит напрямую.
Виртуальные сервера могут одновременно работать в обоих дата-центрах (половина в одном, половина — в другом).
Частично согласен, но тут он ничуть не хуже GRE, который выделен в отдельный тип сети.
Трафик действительно лучше защищать через ipsec, не только из-за секретности, но из-за фильтрации вложенного трафика. Например в моём случае неожиданно внутри GRE без шифрования стал фильтроваться OSPF-трафик, хотя в дата-центре фильтрация выключена — сейчас дата-центр общается на тему этой фильтрации с поставщиком оборудования.
Опять же ipsec не добавляет значительных сложностей с настройкой сети, не добавляет туннелей и т.п. — всё остается прозрачным и может настраиваться автоматически простыми скриптами.
да, mGRE упоминается как часть DMVPN.
Я делаю акцент на том что mGRE доступен в Linux системах из коробки, снимает проблему GRE с кучей туннелей и очень прост в настройке.
Думаю что mGRE вполне может упоминаться в таблице отдельной строкой, наравне с GRE.
В Linux есть еще multipoint GRE — получается один виртуальный интерфейс на большое поличество туннелей, масштабируется он заметно лучше одноточечных GRE.
Все маршрутизаторы получаются в одной подсети + своя подсеть на каждый офис.
На каждом маршрутизаторе настроен один туннельный интерфейс, независимо от количества офисов.
Не увидел в голосовании варианта «нормально» без негативных приписок.
Отношусь к таким ценам нормально и считаю хорошей защитой от киберсквоттеров, которые потом продавали бы красивые домены еще дороже и куча из них просто пылилась бы без дела никому пользы не принося, а тут понятно что зайдя на квартиры.москва или машины.москва или что-то подобное ты получишь именно то что искал. По мне это всем (кроме киберсквоттеров) на пользу: и бизнесу, т.к. могут купить домен по известной понятной цене, а не торговаться вслепую с перекупщиком и пользователям потому что они будут на красивых доменах видеть то что ожидали, а не страницу завешанную непонятными баннерами.
Ага, и теперь туда ходят толпы школоты условно по 10 рублей за отзыв.
Для прикола пробовал зарегистрироваться и поработать на сервисе для ввода капч, дополнительно предлагались и задания вроде найти какой-то сайт через поисковик и побыть на нем какое-то время или оставить отзыв на маркете. Так что моя вера во все сервисы постепенно тает:
пишут настоящие люди с личных компьютеров, своими словами — фиг их тут отфильтруешь.
Как минимум, ему должно быть противно его читать...
1. Противно не значит непонятно
2. Совершенно не факт что должно быть противно.
Для пробы открыл код, который коммитил в 2007-м в личный архив а писал и того раньше. Никакой противности не испытываю — да, сейчас я что-то сделал бы уже по-другому но не более того.
… уж точно не должно хотеться использовать снова
Если какая-то задача уже хорошо была решена 10 лет назад — зачем решать её еще раз, когда можно использовать уже готовое решение? Особенно если она решена понятно и при необходимости это решение легко можно будет поправить под новые ньюансы.
Пользуюсь как сервисом, но открытость кода была одним из важных факторов выбора именно teamlab (начал еще до переименования).
Установочные файлы хранятся локально, архивы скачиваются еженедельно и если по какой-то причине пропадет доступ к сервису — данные всё равно останутся и с ними можно продолжать работать как обычно.
Тестовая миграция из облака в локальную версию прошла успешно.
Снимок является образом виртуальной машины на определённый момент времени, к которому Вы позже можете вернуть машину. Рекомендуется хранить снимки и контрольные точки, которые Вы создаете, вместе со связанными с ними VHD-файлами в безопасном месте.
Увы — при работе со снимками время от времени данные теряются — я лично терял минимум 1 раз + несколько раз терялись у нас в компании, так что пользоваться ими нужно осторожно и только при наличии актуальных резервных копий.
Возможно статья не идеальна, возвращаемся тому же, но другого я не нашел — покажите или изложите лучше.
Я почитал RFC о котором вы говорили, в нем описана общая теория, этот конкретный случай из неё не следует, к тому же практика настройки в нем не описывается вообще.
Что вы не вчера сети настраивать начали я в курсе, около месяца назад читал вашу статью о настройке mgre от 2009 года.
первоначально создаются два LVM-тома и дальше обычная drbd-синхронизация. Поскольку данные с обеих сторон изначально одинаковые (нули для чистого диска или клон одного и того же шаблона) — синхронизация проходит за несколько минут для диска в 10Гб, нагрузки ни на диски ни на канал при этом не создается.
Так же на будущее опробована начальная синхронизация сразу методом записи правильных метаданных. Поскольку начальное содержимое дисков одинаковое — это допускается и занимает несколько секунд уже для любых объёмов. Пока не применяется, т.к. первый способ проще и никаких неудобств на данный момент не доставляет.
В теории — если операции записи идут одна за другой (т.е. рандомно, но в один поток) — 50% вполне хорошо, больше и не будет просто из устройства ceph (клиент передает данные на первый сервер, первый сервер пишет у себя и синхронно передает оставшимся ко количеству реплик, об успешной записи клиент получает подтверждение когда все реплики записаны).
Если писать параллельно — много писателей, много хранилищь, то думаю выжать можно много — добавляйте дисков (серверов) и нагрузка будет распределяться и суммарная скорость будет увеличиваться почти кратно количеству серверов — мониторы в работе не участвуют, клиенты сами распределяют нагрузку по всем серверам.
Он у меня ломался два раза.
1. Один раз совсем, когда я его мучал в режиме: подключить ноду/отключить ноду/подключить ноду/отключить ноду несколько раз подряд прямо в процессе репликации, при этом что-то делал с rbd-образами и включал/выключал мониторы. В какой-то момент часть данных сказала «я не знаю где нахожусь, откуда реплицироваться и т.п.».
Второй раз уже в обычном режиме, сломалась клиентская часть — просто работал с rbd-образами: создавал, удалял, блокировал, разблокировал и пришел к такому состоянию когда с конкретно этим образом сделать уже ничего нельзя — он подвис на хост-системах где монтировался. Т.е. можно например подмонтировать его на другой ноде, но не на первой. Первую надо ребутить целиком.
Про дата-центры я тоже думал что они не зависят друг от друга и поддержка так говорила.
Потом в один прекрасный день (этим летом) у них сломалась центральная железка и интернет упал в обоих «независимых» дата-центрах, собственно поэтому дата-центры теперь вообще от разных компаний и в разных городах.
Виртуальные сервера могут одновременно работать в обоих дата-центрах (половина в одном, половина — в другом).
Трафик действительно лучше защищать через ipsec, не только из-за секретности, но из-за фильтрации вложенного трафика. Например в моём случае неожиданно внутри GRE без шифрования стал фильтроваться OSPF-трафик, хотя в дата-центре фильтрация выключена — сейчас дата-центр общается на тему этой фильтрации с поставщиком оборудования.
Опять же ipsec не добавляет значительных сложностей с настройкой сети, не добавляет туннелей и т.п. — всё остается прозрачным и может настраиваться автоматически простыми скриптами.
Я делаю акцент на том что mGRE доступен в Linux системах из коробки, снимает проблему GRE с кучей туннелей и очень прост в настройке.
Думаю что mGRE вполне может упоминаться в таблице отдельной строкой, наравне с GRE.
geektimes.ru/post/48276/
Все маршрутизаторы получаются в одной подсети + своя подсеть на каждый офис.
На каждом маршрутизаторе настроен один туннельный интерфейс, независимо от количества офисов.
Отношусь к таким ценам нормально и считаю хорошей защитой от киберсквоттеров, которые потом продавали бы красивые домены еще дороже и куча из них просто пылилась бы без дела никому пользы не принося, а тут понятно что зайдя на квартиры.москва или машины.москва или что-то подобное ты получишь именно то что искал. По мне это всем (кроме киберсквоттеров) на пользу: и бизнесу, т.к. могут купить домен по известной понятной цене, а не торговаться вслепую с перекупщиком и пользователям потому что они будут на красивых доменах видеть то что ожидали, а не страницу завешанную непонятными баннерами.
Для прикола пробовал зарегистрироваться и поработать на сервисе для ввода капч, дополнительно предлагались и задания вроде найти какой-то сайт через поисковик и побыть на нем какое-то время или оставить отзыв на маркете. Так что моя вера во все сервисы постепенно тает:
пишут настоящие люди с личных компьютеров, своими словами — фиг их тут отфильтруешь.
1. Противно не значит непонятно
2. Совершенно не факт что должно быть противно.
Для пробы открыл код, который коммитил в 2007-м в личный архив а писал и того раньше. Никакой противности не испытываю — да, сейчас я что-то сделал бы уже по-другому но не более того.
Если какая-то задача уже хорошо была решена 10 лет назад — зачем решать её еще раз, когда можно использовать уже готовое решение? Особенно если она решена понятно и при необходимости это решение легко можно будет поправить под новые ньюансы.
В тарифе указывается именно % процессорной нагрузки, а дальше всё зависит от того как сайт написан. Сами запросы 1Гб не считает и не ограничивает.
Установочные файлы хранятся локально, архивы скачиваются еженедельно и если по какой-то причине пропадет доступ к сервису — данные всё равно останутся и с ними можно продолжать работать как обычно.
Тестовая миграция из облака в локальную версию прошла успешно.
Увы — при работе со снимками время от времени данные теряются — я лично терял минимум 1 раз + несколько раз терялись у нас в компании, так что пользоваться ими нужно осторожно и только при наличии актуальных резервных копий.
Я почитал RFC о котором вы говорили, в нем описана общая теория, этот конкретный случай из неё не следует, к тому же практика настройки в нем не описывается вообще.
Что вы не вчера сети настраивать начали я в курсе, около месяца назад читал вашу статью о настройке mgre от 2009 года.
Да, фильтрует.