В определенном смысле уже можно пользоваться на тех устройствах, куда можно OpenWRT установить (Tinc and OpenWRT). На микротики точно можно установить OpenWRT, например на 951G, 951Ui. Но, во-первых, непонятно будет ли tinc работать на mips, во-вторых, чистый ROS мне ближе. Думаю что нужно написать в Mikrotik и предложить рассмотреть такую возможность. Хотя бы в варианте сервер (к микротику) + клиент (микротик к одному-двум клиентам), т.е. получить небольшой сегмент. Чем черт не шутит! OpenVPN они так и не допилили, может tinc сделают!
Кстати, зря заминусовали человека. tincvpn и правда весьма интересный. У него минус основной один — он не кроссплатформенный (в настоящее время это означает что нет поддержки в Android, железе). Зато почти полноценный mesh. Также требует некоторой усидчивости при написании конфигов, ведь конфиги и ключи должны быть идентичны на всех членах сети. Решается разными способами: git, ansible, etc. или просто руками, особенно для случаев вроде «кластера» выше, всего два члена сети. Ну и доступные IP крайне желательны (что в серверах уже присутствует).
А еще из тинков можно сделать такой боооольшой бонд интерфейс ;)
Это помогает только со сбросом кеша (например когда файлы менялись на вложенных дисках напрямую), но при монтировании есть привязка к физической файловой системе и если поверх смонтировано что-то еще, то aufs его не учитывает (а еще, не позволяет отмонтировать — хаки через удаление/изменение дисков, входящих в объединение, показали что не стоит оно того, проще все перемонтировать — будет гарантированный результат).
Я сейчас сделал простой тест (overlayfs):
1) смонтировал поверх /d1 папку со своим содержимым через bind
2) проверил — в /d123 содержимого нет ни сразу, ни после сброса кеша, ни после remount
Т.е. overlayfs продолжает «видеть» файловую ниже, а не ту, что смонтировали поверх (касается и нормальных non-bind mount).
Не так. И это заметно в нюансах.
Насчет записи я подчеркнул что не тестировал aufs на параллельной записи, да и просто на запись не использую по одной очень важной причине — aufs требует полноценного перемонтирования при отмонтировании диска из перечня, а вот mhddfs это спокойно делает. Чтобы было понятно — когда список дисков это пустые директории /d1, /d2, /d3, то смонтировав их в /d123 и затем примонтировав настоящие диски в /d1, /d2, /d3 мы сразу же получим объединенное содержимое для mhddfs, но не для aufs/overlayfs, которые покажут пустоту, как и до монтирования настоящих дисков.
Вместе с тем, aufs/overlayfs заметно быстрее работает, более стабилен и меньше грузит процессор. Поэтому для файлового хранилища я делаю виртуальные объединенные read-only папки на overlayfs. И перемонтирую их когда меняются входящие в состав диски.
Я тоже пострадал немного когда перешел на linux-4 ядро откуда выкинули aufs (Debian), но в настоящий момент OverlayFS выглядит ничем не хуже (для моих сценариев).
Из моего опыта (советы ниже больше касаются mhddfs, но частично применимы к aufs/overlayfs) настоятельно советую писать файлы напрямую на диски, т.к. запись в объединенную папку может привести к вылету (для mhddfs).
Количество параллельных запросов на запись никак не ускорит работу (для mhddfs — aufs/overlayfs не тестировал так)! Запись идет последовательно до заполнения (с учетом mlimit для mhddfs) первого диска по списку, потом второго и т.д. до последнего. А еще это позволяет иметь несколько копий одного и того же файла (виден будет первый, но если его удалить, то второй, если и его удалить (что интересно, удалять можно прямо с объединенной папки, каждая итерация будет удалять вышестоящий файл!), то третий и так до последнего диска в списке).
Для поклонников RAID: ничто не мешает объединять уже защищенные массивы, получив, например, аналог RAID1+0, только предсказуемый и более отказоустойчивый (и, разумеется, менее быстрый если не думать головой, а вот если ее приложить, то скорость будет такая же или чуть выше).
Т.е. опять же, планирование и еще раз планирование! И тогда результат будет очень и очень хорошим.
Использую его с 4-го ядра (когда AuFS выкинули и заменили на OverlayFS) для объединения 50+ точек монтирования. Работает неплохо, скорость выше чем через mhddfs (хотя его я тоже по-своему люблю — главное что он очень простой, однако плохо подходит для записи).
Там довольно простой алгоритм, какой путь идёт раньше, тот и будет мастером, дубликат не виден:
> /srv/storage-storage;/srv/system-storage -> /srv/storage
echo 1 > /srv/storage-storage/test
echo 2 > /srv/system-storage/test
Но без анализа возможностей исходной машины можно сделать неверные выводы! Как раз у нас похожие вопросы есть с ESXi хостами. И то, как делает бекапы Veeam, не позволяет (?) сделать их быстрее 30 Мб/сек! Возможности целевого хранилища не при чем.
В самом Veeam Backup & Replication нет вариантов как делать бекапы с ESXi. Только один способ, да включение/выключение CBT (блочный трекинг).
Возможно, проблема больше в Veeam, чем в ESXi, но хотелось бы понять можно ли изменить ситуацию на стороне ESXi.
Раз уж затронули такой важный вопрос как производительность, то может стоит глубже проанализировать нюансы с настройкой локальных дисковых массивов?
Столкнулся со странной проблемой, когда при тесте скорости чтения/записи (но первично именно чтение) внутри виртуалки все хорошо, а вот если читать файл напрямую с ESXi (в консоли), то скорость в районе 33 Мб/сек (как USB 2.0 почти!) и никак выше не выходит. Что по сети, что локально (например через dd).
Заметил это когда пытался использовать Veeam для бекапа с ESXi и обнаружил катастрофическое падение скорости по сравнению с сервером на Hyper-V. Скорости 20-30 Мб/сек против 76 Мб/сек (почти гигабит) у Hyper-V. Тестировал сеть между ESXi серверами — она около 800 мегабит, т.е. в сеть не упираемся. Все исключительно из-за дисковой. Которая представляет собой RAID10 массив из SAS дисков на контроллере P410.
Куда копать, что смотреть? Думаю что не только я буду вам благодарен!
Интересно что если не включать Flash, то нет утечки адреса через него, но проверка на двухсторонний ping проваливается.
А если включить Flash, то реальный адрес утекает (вот же какая засада!), зато проверка на двухсторонний ping проходит — зеленая.
Это фишка или баг?
Поймите, многие вам благодарны за такой ход, даже не представляю как можно было бы познакомиться с вашим продуктом иначе, я также планирую убедить своих CE развернуть… Однако это не должно выглядеть подачкой, мол мы такие хорошие, «берите что дают и не возмущайтесь».
Как я это понимаю, данный шаг (CE) сделан был не просто так, возможно вы были вынуждены его сделать и именно поэтому началась подобная отстройка от клиентов «второго сорта».
И претензии всего-то к тому, что использование CE осложняется невнятным «Please login to access the full list of documentation». Что это такое, full list? Вот вроде бы по вашим словам на portal.nutanix.com/#/page/docs «полная документация у нас открыта для всех», а сайт говорит что нет. Кто-то недоговаривает?
Как вести себя вашим потенциальным клиентам? Личное ощущение (говорю только за себя) что если ты не сконвертируешься в платного клиента, то рискуешь что рано или поздно что-нибудь нездоровое вылезет (изменение лицензии например — я так сразу и не понял что CE лицензию еще активировать надо). Выше RedHat упомянули, у них роль CE выполняет CentOS с которой все весьма хорошо, если ты вложишься в нее, то не рискуешь своими инвестициями, тебя не заставят перейти на платный RedHat. Насчет Nutanix CE пока такого (повторюсь, по ощущениям!) сказать нельзя.
2 робота = 1 комплект. Т.е. это фактически один грузчик с тележкой. И не три смены, а две (из текста: «сможет работать по 16 часов в сутки») и еще неизвестно как долго он сможет выдержать 100% загрузку.
Все по своим местам экономика расставит. Что будет выгоднее, то и будут использовать. А кто-то будет первым и за все это заплатит ;)
Это официальная политика такая?
KB у Vmware открыт, и многие вещи без него было бы делать в разы сложнее.
Не укладывается в голове ваша новая политика, как-то по-детски наивно, жалеете что в бесплатный доступ выкатили решение? Лучше сразу скажите, чем палки в колеса ставить.
Т.е. не вдаваясь глубоко в экономику, получается что исходя из 4 лет службы, в месяц два робота обходятся около $2700 (без учета процентов, ремонтов, простоев и т.п.).
Если большее количество роботов не позволит получить больший совокупный эффект (вроде как 2+2=5), то использование таких роботов будет скорее маркетинговым приемом, чем реальной потребностью.
Но, вообще, радует что такие крутые штуки начали появляться!
А еще из тинков можно сделать такой боооольшой бонд интерфейс ;)
Я сейчас сделал простой тест (overlayfs):
1) смонтировал поверх /d1 папку со своим содержимым через bind
2) проверил — в /d123 содержимого нет ни сразу, ни после сброса кеша, ни после remount
Т.е. overlayfs продолжает «видеть» файловую ниже, а не ту, что смонтировали поверх (касается и нормальных non-bind mount).
Насчет записи я подчеркнул что не тестировал aufs на параллельной записи, да и просто на запись не использую по одной очень важной причине — aufs требует полноценного перемонтирования при отмонтировании диска из перечня, а вот mhddfs это спокойно делает. Чтобы было понятно — когда список дисков это пустые директории /d1, /d2, /d3, то смонтировав их в /d123 и затем примонтировав настоящие диски в /d1, /d2, /d3 мы сразу же получим объединенное содержимое для mhddfs, но не для aufs/overlayfs, которые покажут пустоту, как и до монтирования настоящих дисков.
Вместе с тем, aufs/overlayfs заметно быстрее работает, более стабилен и меньше грузит процессор. Поэтому для файлового хранилища я делаю виртуальные объединенные read-only папки на overlayfs. И перемонтирую их когда меняются входящие в состав диски.
Количество параллельных запросов на запись никак не ускорит работу (для mhddfs — aufs/overlayfs не тестировал так)! Запись идет последовательно до заполнения (с учетом mlimit для mhddfs) первого диска по списку, потом второго и т.д. до последнего. А еще это позволяет иметь несколько копий одного и того же файла (виден будет первый, но если его удалить, то второй, если и его удалить (что интересно, удалять можно прямо с объединенной папки, каждая итерация будет удалять вышестоящий файл!), то третий и так до последнего диска в списке).
Для поклонников RAID: ничто не мешает объединять уже защищенные массивы, получив, например, аналог RAID1+0, только предсказуемый и более отказоустойчивый (и, разумеется, менее быстрый если не думать головой, а вот если ее приложить, то скорость будет такая же или чуть выше).
Т.е. опять же, планирование и еще раз планирование! И тогда результат будет очень и очень хорошим.
> /srv/storage-storage;/srv/system-storage -> /srv/storage
echo 1 > /srv/storage-storage/test
echo 2 > /srv/system-storage/test
# cat /srv/storage/test
1
# rm /srv/storage-storage/test
# cat /srv/storage/test
2
Возможно, проблема больше в Veeam, чем в ESXi, но хотелось бы понять можно ли изменить ситуацию на стороне ESXi.
Столкнулся со странной проблемой, когда при тесте скорости чтения/записи (но первично именно чтение) внутри виртуалки все хорошо, а вот если читать файл напрямую с ESXi (в консоли), то скорость в районе 33 Мб/сек (как USB 2.0 почти!) и никак выше не выходит. Что по сети, что локально (например через dd).
Заметил это когда пытался использовать Veeam для бекапа с ESXi и обнаружил катастрофическое падение скорости по сравнению с сервером на Hyper-V. Скорости 20-30 Мб/сек против 76 Мб/сек (почти гигабит) у Hyper-V. Тестировал сеть между ESXi серверами — она около 800 мегабит, т.е. в сеть не упираемся. Все исключительно из-за дисковой. Которая представляет собой RAID10 массив из SAS дисков на контроллере P410.
Куда копать, что смотреть? Думаю что не только я буду вам благодарен!
А если включить Flash, то реальный адрес утекает (вот же какая засада!), зато проверка на двухсторонний ping проходит — зеленая.
Это фишка или баг?
Как я это понимаю, данный шаг (CE) сделан был не просто так, возможно вы были вынуждены его сделать и именно поэтому началась подобная отстройка от клиентов «второго сорта».
И претензии всего-то к тому, что использование CE осложняется невнятным «Please login to access the full list of documentation». Что это такое, full list? Вот вроде бы по вашим словам на portal.nutanix.com/#/page/docs «полная документация у нас открыта для всех», а сайт говорит что нет. Кто-то недоговаривает?
Как вести себя вашим потенциальным клиентам? Личное ощущение (говорю только за себя) что если ты не сконвертируешься в платного клиента, то рискуешь что рано или поздно что-нибудь нездоровое вылезет (изменение лицензии например — я так сразу и не понял что CE лицензию еще активировать надо). Выше RedHat упомянули, у них роль CE выполняет CentOS с которой все весьма хорошо, если ты вложишься в нее, то не рискуешь своими инвестициями, тебя не заставят перейти на платный RedHat. Насчет Nutanix CE пока такого (повторюсь, по ощущениям!) сказать нельзя.
Буду благодарен за комментарии без эмоций.
Все по своим местам экономика расставит. Что будет выгоднее, то и будут использовать. А кто-то будет первым и за все это заплатит ;)
KB у Vmware открыт, и многие вещи без него было бы делать в разы сложнее.
Не укладывается в голове ваша новая политика, как-то по-детски наивно, жалеете что в бесплатный доступ выкатили решение? Лучше сразу скажите, чем палки в колеса ставить.
Если большее количество роботов не позволит получить больший совокупный эффект (вроде как 2+2=5), то использование таких роботов будет скорее маркетинговым приемом, чем реальной потребностью.
Но, вообще, радует что такие крутые штуки начали появляться!