Вместо распаковки архивов я бы использовал chocolatey — это гораздо более элегантное решение. У puppet существует провайдер package chocolatey. Установка mongodb выглядела бы приблизительно так:
Если не используете deployment систему (для .net очень сильно рекомендую Octopus Deploy) — я бы тогда использовал chocolatey для развертывания своего софта. Пакуете свой софт в nuget-package и устанавливаете этот пакет из своего источник). А учитывая еще то, что в puppet есть модуль iis, то получилось бы примерно следующее:
class www_site_com {
include packages::iis
include iis::certs::star_site_com
$sitename = 'www.site.com'
#Получаем имя сервера для последующего обращения к нему
$srvsubstname = downcase($::hostname)
#Создаем директорию IIS
file { "c:\\inetpub\\wwwroot\\$sitename":
ensure => "directory",
}
#Создаем запись в host файле для обращения к серверу по его имени локально
host { "${srvsubstname}$sitename":
ip => '127.0.0.1',
}
#Создаем Application Pool
iis_apppool {$sitename:
ensure => present,
managedpipelinemode => 'Integrated',
managedruntimeversion => 'v4.0',
autostart => true,
require => Class['packages::iis'],
}
#Создаем Site & Bindings
iis_site {$sitename:
ensure => present,
bindings => ["http/*:80:$sitename","http/*:80:${srvsubstname}$sitename","https/*:80:$sitename","https/*:80:${srvsubstname}$sitename"],
serverautostart => true,
require => Class['packages::iis','iis::certs::star_site_com'],
}
#Создаем Application
iis_app {"$sitename/":
ensure => present,
applicationpool => $sitename,
require => Class['packages::iis'],
}
#Указываем директорию в которой находится наше приложение
iis_vdir {"$sitename/":
ensure => present,
iis_app => "$sitename/",
physicalpath => "c:\\inetpub\\wwwroot\\$sitename",
require => [Class['packages::iis'],File["c:\\inetpub\\wwwroot\\$sitename"]],
}
#Устанавливаем нужное приложение из своего nuget-feed
package { "api_deploy":
ensure => installed,
provider => chocolatey,
source => 'https://myfeed.example.com/api/v2'
}
}
Таким образом, все действия по установке приложения api_deploy происходят в chocolateyInstall.ps1 (док), и сам манифест остается чистым.
Про порядок exec было верно подмечено, у Вас нет ни одной зависимости, и все будет запускаться в разнобой, используйте ordering.
Очень рекомендую использовать theforeman, так-как в нем не только функционал назначения классов, но еще есть возможность управлять инстансами в AWS прямо из панели управления theForeman (очень удобно создавать инстансы прямо там из заданного образа AMI с нужными классами в один клик!).
Я постоянно слушаю с телефона пока сижу в пробках. Интернет у нас работает отлично. Когда прихожу в ДЦ — слушаю с телефона.
Вообще, у меня на телефоне и компьютере нет локальных коллекций музыки. Незачем мне это. Когда-то было, но понял что я и половины не слушаю. Теперь пользуюсь Spotify, люблю его. Для того, чего там нет использую приложение vk на телефоне (в основном русские исполнители). Имхо локальные MP3 коллекции — это архаизм. Все должно быть в облаке (своем или чужом).
Прекрасная вещь. Сам давно пользуюсь на HTPC. Единственная проблема — не работает на MacOS. Приходится на виртуалке держать прокси. Также это прекрасная возможность смотреть русское/любое нелокальное телевидение за океаном. P2P позволяет не обращать внимания на переодические проблемы с «тихоокеанским кабелем».
VK — помойка, и я полностью согласен с тем, что в США ее многие считают «XXX» сайтом и аналогом пиратской бухты, ведь так оно и есть :)
Обсуждать руководство сайта не буду, все и так все знают.
А в России все еще хуже, необходимо еще не обращать внимание на бюрократию и блат. Стартапы существуют, но в большинстве своем до тех пор, пока не переходят дорогу кому-нибудь. А если задумка стоящая, то ее пути обязательно пересекаются с какой-нибудь организацией, которой владеет хороший друг губернатора…
К счастью это не конец, нужно не бояться а искать другие выходы, а до этого просто действовать не только амбициозно, но и достаточно аккуратно.
В Amazon Kindle 3G начали использовать интегрированные симки достаточно давно. Интегрированные симки — это здорово, только жаль что в Штатах нельзя просто так взять и купить симку для «легкого json траффика» подешевке, тарифы на потребительскую связь тут жуткие. Будем надеяться что симка будет со включенным в стоимость трафиком (пускай и с ограничением), но без абонентской платы в $15 в месяц и бояться что трафик перевалит за 250MB: (AT&T)
Отказался от этого девайса по этим же причинам. Пробовал патчить для аппаратного ускорения, все равно все тормозит ужасно, особенно через сеть. Расстроился, купил raspberry pi поставил raspbmc — все прекрасно из коробки, не хватает только SPDIF выхода, но это не беда.
Рассказываю как самый что ни на есть очевидец.
Обычно если деятельность компании — IT, то структуры производят контрольную закупку. Причем это очень заметно — просят поставить сразу софта на огромную сумму и часто все на один компьютер. Здесь тяжело не заметить что это подстава (котрольная закупка). Старый завод, Пустой Pentium 4 4GBRam, подозрительные люди, просьба установить Windows, Archicad, Autocad, Компас, 3dsmax, Photoshop, Office и еще не бог весть что. Могут согласиться на «хорошие» деньги за услуги установки. Спрашивают лицензионное ли ПО?
Если проверка лицензионности софта проходит у организации, которая не занимается IT услугами (установка/настройка/поддержка) — скорее всего это повод подкопаться. Если те кто копают — серьезные люди — отвертеться будет очень тяжело, только хороший адвокат либо решение вопроса который стал поводом для проверки. Поэтому мой совет тем, кто планирует деятельность которая будет сильно напрягать конкурентов / администрацию города /… — не пренебрегайте вопросами лицензий. Если нет спец софта, а только документы и интернет — вполне можно обойтись Linux (проверено на себе). Лицензионный Windows SBS Server и RDP Вам в помощь (как доказательство что все что должно быть лицензировано — у Вас лицензировано).
Огромная сложность еще состоит в том, что судьи в данной сфере очень слабо владеют вопросом, и поэтому влияние обвинителей может сыграть на руку, но не Вам.
Как верно было подмечено — ставьте триалы, потом только покупка. Также если хорошо поискать можно откопать множество «подарочных» серийников, которые Вы могли получить по акциям или в подарок с покупкой софта. Если есть документы на такой софт — ставьте его. Если документов нет — лучше не испытывать судьбу. Как было сказано в предыдущем коментарии — эцелопы бывают ох какие упрямые. В конечном счете нужно понимать что сколько стоит и какая ответственность грозит. Кстати, органы всегда пытаются выйти на ответственность юр.лица, т.к. у него ответственность на много выше, говорят «Сотрудничай с нами, и тебе ничего не будет» — но не факт что все так и будет.
Вообще, в этом всем есть здравый смысл, но я считаю что софт покупать нужно если ты зарабатываешь на нем деньги.
Если деньги не зарабатываются, либо мало — тебе должно быть достаточно пары триалов, либо bizspark для MS (на года 3 точно хватит).
Мой совет — будьте осторожны, и все будет хорошо :)
Попробуйте logstash, не пожалеете. Умеет принимать syslog, snmp traps и многое другое, хранит все в elastic search, по любым критериям можно настроить мониторинг, nagios алерты и вообще тонну всего остального. И все это при правильной настройки — real time!
Мы успешно его используем для мониторинга приложений, а также для анализа бизнес-метрик. Вот так выглядит front-end.
Одним словом — OpenSource Splunk :)
Спасибо за ответ, статья давалась в большей степени как призыв к использованию системы управления конфигурациями, показать на сколько она упрощает жизнь админу.
Как я уже сказал, я совершенно не против виртуализации, но в случае моей инфраструктуры это не вариант по причине серьезных требований к производительности, к тому же данный пост покрывает установку на bare metal, что приходится делать, даже если есть виртуализированные среды.
>Это вы зря :)
Если зря — приношу извинения.
>Отлично работает, если изначально об этом подумать, виртуализация дает отличную масштабируемость и апдейт на новый сервер занимает считанные минуты(если просто замена железки, и диски виртуалок доступны для нового сервера изначально локально), достаточно развернуть гипервизор, и всё, тащи виртуалки туда и давай им больше ресурсов.
Все верно, но мир не идеален, и инфраструктуры переходят по наследству от инженера к инженеру, это тоже нужно понимать :)
>А я бы клонировал эталонную машину :)
Здесь не соглашусь, мое мнение по этому поводу — это лишает гибкости в дальнейшем. Эталонная машина — это еще одно «то» что нужно поддерживать и обновлять достаточно часто, а если начнут появляться требования в различии двух машин — еще чаще.
Господа хабравчане минусуют, но еще кроме Вас не отписался. Надеюсь все понимают, что пост — это часть одного большого целого об использовании системы управления конфигураций puppet в большой инфраструктуре, а не просто пост о том, как поставить винду :)
Не совсем ясно за что минус, кто поставил — отпишитесь пожалуйста.
Позвольте немного уточнить мою позицию и расставить точки над «i» (наконец-то я не с телефона:))
Во-первых, iDrac никогда не заменит массовую установку через pxe. Представьте, у Вас под 200 серверов, возраст которых от 5 лет до нескольких месяцев. Изначалльно Dell не включал никакой iDrac в стандартную поставку, а сейчас включает только базовый вариант. Вам нужно обновить Windows на 10 из старых серверов. Что будет более эффективно, переставить ОС удаленно через pxe и WDS/kickstarter со всеми апдейтами или делать апгрейд сервера, устанавливая сначала iDrac, а потом монтируя ISO тысячалетней давности через сеть, устанавливая 1-2 сервера за раз, а потом полдня обновляя систему? Конечно iDrac мало пригоден в данном случае.
Во-вторых, изначально IP KVM — решение экономически более выгодное чем iDrac (сравните цены) + более гибкое (можно подключить куда угодно).
Не до конца понимаю как Вы видите мою инфраструктуру сидя за монитором, что беретесь судить о том, как «на деле»:
>На деле, парк из сотен физических серверов разносольным никто не делает
Вы почему-то рассматриваете инфраструктуру «с нуля» — только тогда есть возможность выбирать идеальное решение. К сожалению реалии жизни таковы, что работа инженера — это в первую очередь поддержка текущей инфраструктуры, и соответственно всего того, что делает деньги и что должно работать СЕЙЧАС, а уже потом ее улучшение. Возможно, если это унылый датацентр, где можно положить/переренести десяток сервисов — да, но не в моем случае.
Другая несостыковка — это не работает в среде стартапа, где темпы роста компании намного больше чем возможность оглянуться назад и сделать рефакторинг. Это роскошь, ведь те самые «первые» серверы обычно выполняют четко поставленные задачи. А дальше — рост, рост, рост. Хочется виртуализировать — некогда, нужно расти… Время бежит, модель сервера сменяется за моделью, и проект растет, и вот пора уже сервисы со старых серверов переносить — виртализировать? — нет, слишком медленно — поэтому и переносим. Сегодня картина несомненно улучшилась, и можно сделать выбор в пользу виртуализации для определенного круга сервисов, но здесь встает другой вопрос — инфраструктура уже существует и делает деньги, поэтому нужна миграция. Представьте, что у Вас высоконагруженный сайт с миллионом уникальных пользователей в день, где каждая минута простоя — тысячи $$$ упущенной выгоды. Выходит, что это перерастает в отдельный проект, который имеет свой приоритет перед другими задачами, а это уже совсем другая история. Ах да, рост, рост, рост. Понимаете о чем я? Да, все упирается во (время + деньги) = деньги ^ 2.
В-третьих, я продолжаю слышать нотки теории в Вашем комментарии. Все не так-то просто. Размещая 10 виртуалок на одном хосте Вы кладете «все яйца в одну корзину». В реальных условиях Ваши 10:1 превращается как минимум 10:2 + надежный и быстрый NAS + инфраструктура для надежной/быстрой передачи данных, а это, как минимум, 2x10Gb/s свитча стоимостью около $10 000. Все остальные конфигурации не отвечают нашим требованиям (медленно/ненадежно). Вы написали про «При определенных условиях уже можно кластер поднять» — для меня это единственное верное решение. Никаких условий для production среды нет — только так. К тому же со стороны сервиса надежность железного сервера выше чем надежность 10 виртуалок на 1м сервере, потому что на один сервис приходится один полностью, как минимум, вдвойне зарезервированный (redundant) сервер (CPU, Memory, PSU), в то время как в соотношении 10:1 на каждую виртуалку приходится только часть зарезервированного сервера, но я думаю это и так понятно что это означает.
В-четвертых, с чего Вы взяли что в моей боевой среде нужны «физически немощные сервачки»? — В реальности объем данных который обрабатывается огромен (в рамках данного сравнения), и использование виртуализации в такой системе не оправдано. Ну не заменить реальное железо и прямой доступ к IO в моем случае, никак не заменить, а с RAM — вообще беда (какой смысл слой виртуализации если 100% времени на хосте 1 виртуалка — удобство? Я лучше выберу производительность, так как именно она делает деньги. Делали тесты — знаем.
В-пятых, конечно, виртуализацию я люблю, и конечно мы ее используем, только с умом. Staging, Development и все что не требует больших ресурсов и 99.9% аптайма — все виртуализировано. OpenStack для разрабов, но там память у инстанса выставлена максимум 8GB, и это никто не использует…
Если бы сейчас мне предложили проект, который бы получил пользу от гибкости, где нужно было бы конфигурировать типовые машинки с небольшим количеством памяти и CPU — я бы с великой радостью все сделал виртуализированно НО все так же использовал бы PXE, так-как это удобно, гибко и быстро! Здесь исключение составят 100% клоны, где можно использовать шаблоны и снепшоты — вообще красота!
Еще раз повторюсь, я не идеалист, и решаю реальные проблемы в реальных ситуациях силами реальных людей и используя реальные деньги, а также реальное время. Может быть за это мне и платят реальными деньгами :)
Прошу прощения за сбивчивый русский, в России не живу уже 3 года.
iDrac — Хорошая штука, но мне это не подходит по нескольким причинам: это дополнительная лицензия, дополнительные настройки. К тому же делать апгрейд старых серверов не всегда представляется возможным, а решение должно быть максимально универсальным.
Спасибо за статью, было интересно почитать о Вашем опыте. Сколько работаю в сфере IT — столько задумываюсь о том, что свое собственное решение всегда лучше (проще, направлено на конкретную задачу) — до того момента, пока оно работает. Как только что-то меняется в системе на которую направлено решение, либо необходимо добавить новый функционал — возникают сложности, потому что к тому моменту обычно забываешь о скрипте/программе/решении и деталях как оно все работает. И вот тут я обычно задумываюсь — все-таки нужно использовать сторонний софт, с очевидными преимуществами подхода: поддержкой занимается команда разработчиков, чья работа поддерживать этот софт. Они придерживаются плана релизов, и добавляют новые фичи относительно регулярно, т.к. это тоже их работа. Плюс качество продукта, обычно, заметно выше чем скрипт (пускай даже продвинутый, с множеством параметров и вариантов логики.
Обычно такие рассуждения меня приводят к мыслям, что миру нужна система, которая была бы модульная, где модуль я могу написать сам, а другие придут из коммьюнити. Но ключевым должно быть то, что продукт должен быть достаточно user-friendly, чтобы его смогли использовать простые эникейщики. Поставил ядро, загрузил модули, указал пути (причем в GUI) — пользуйся. Я сравниваю с системой управления конфигурациями puppet, где такая же схема ядро/модули.
Сейчас для бекапа системы я использую софт из семейства Акронис.
Акронис не менее удобен для бекапов самих файлов — инкрементные бекапы (история файлов, соответственно), возможность подключить образ как диск, а также возможность хранить данные в облаке (FTP, S3, Acronis Cloud).
Также для Windows есть прекрасная программа goodsync, для Ваших нужд ее должно вполне хватить, на уровне файлов она работает точно так же как RSYNC, но имеет возможность также делать синхронизацию/бекап в облако. Программа хорошо поддерживается и постоянно развивается.
К сожалению никак не доходят руки до opensource проекта amanda backup, может кто пользовался? amanda.zmanda.com — система позволяет упорядочить все бекапы внутри инфрастрктуры (как заявляет сайт — аналог bacula с поддержкой более высокого уровня)
Сейчас это ворнинг, Вы все верно говорите, как раз в подпланах номера 2 кроется проблема, где нужно делать анализ. Но беда в том, что этих ворнингов накапливается столько, что психологически для админов они перестают быть ворнингами, и становятся нормой, что не есть хорошо, а анализ делать… Ну кто его сделает кроме меня? :)
Выходит что при текущей загруженности моих человекочасов нужно попросту отключать ненужные проверки, до тех пор пока не возникнет потребность их мониторить…
Если не используете deployment систему (для .net очень сильно рекомендую Octopus Deploy) — я бы тогда использовал chocolatey для развертывания своего софта. Пакуете свой софт в nuget-package и устанавливаете этот пакет из своего источник). А учитывая еще то, что в puppet есть модуль iis, то получилось бы примерно следующее:
Таким образом, все действия по установке приложения api_deploy происходят в chocolateyInstall.ps1 (док), и сам манифест остается чистым.
Про порядок exec было верно подмечено, у Вас нет ни одной зависимости, и все будет запускаться в разнобой, используйте ordering.
Очень рекомендую использовать theforeman, так-как в нем не только функционал назначения классов, но еще есть возможность управлять инстансами в AWS прямо из панели управления theForeman (очень удобно создавать инстансы прямо там из заданного образа AMI с нужными классами в один клик!).
Удачи!
Вообще, у меня на телефоне и компьютере нет локальных коллекций музыки. Незачем мне это. Когда-то было, но понял что я и половины не слушаю. Теперь пользуюсь Spotify, люблю его. Для того, чего там нет использую приложение vk на телефоне (в основном русские исполнители). Имхо локальные MP3 коллекции — это архаизм. Все должно быть в облаке (своем или чужом).
VK — помойка, и я полностью согласен с тем, что в США ее многие считают «XXX» сайтом и аналогом пиратской бухты, ведь так оно и есть :)
Обсуждать руководство сайта не буду, все и так все знают.
К счастью это не конец, нужно не бояться а искать другие выходы, а до этого просто действовать не только амбициозно, но и достаточно аккуратно.
(AT&T)
Обычно если деятельность компании — IT, то структуры производят контрольную закупку. Причем это очень заметно — просят поставить сразу софта на огромную сумму и часто все на один компьютер. Здесь тяжело не заметить что это подстава (котрольная закупка). Старый завод, Пустой Pentium 4 4GBRam, подозрительные люди, просьба установить Windows, Archicad, Autocad, Компас, 3dsmax, Photoshop, Office и еще не бог весть что. Могут согласиться на «хорошие» деньги за услуги установки. Спрашивают лицензионное ли ПО?
Если проверка лицензионности софта проходит у организации, которая не занимается IT услугами (установка/настройка/поддержка) — скорее всего это повод подкопаться. Если те кто копают — серьезные люди — отвертеться будет очень тяжело, только хороший адвокат либо решение вопроса который стал поводом для проверки. Поэтому мой совет тем, кто планирует деятельность которая будет сильно напрягать конкурентов / администрацию города /… — не пренебрегайте вопросами лицензий. Если нет спец софта, а только документы и интернет — вполне можно обойтись Linux (проверено на себе). Лицензионный Windows SBS Server и RDP Вам в помощь (как доказательство что все что должно быть лицензировано — у Вас лицензировано).
Огромная сложность еще состоит в том, что судьи в данной сфере очень слабо владеют вопросом, и поэтому влияние обвинителей может сыграть на руку, но не Вам.
Как верно было подмечено — ставьте триалы, потом только покупка. Также если хорошо поискать можно откопать множество «подарочных» серийников, которые Вы могли получить по акциям или в подарок с покупкой софта. Если есть документы на такой софт — ставьте его. Если документов нет — лучше не испытывать судьбу. Как было сказано в предыдущем коментарии — эцелопы бывают ох какие упрямые. В конечном счете нужно понимать что сколько стоит и какая ответственность грозит. Кстати, органы всегда пытаются выйти на ответственность юр.лица, т.к. у него ответственность на много выше, говорят «Сотрудничай с нами, и тебе ничего не будет» — но не факт что все так и будет.
Вообще, в этом всем есть здравый смысл, но я считаю что софт покупать нужно если ты зарабатываешь на нем деньги.
Если деньги не зарабатываются, либо мало — тебе должно быть достаточно пары триалов, либо bizspark для MS (на года 3 точно хватит).
Мой совет — будьте осторожны, и все будет хорошо :)
Мы успешно его используем для мониторинга приложений, а также для анализа бизнес-метрик. Вот так выглядит front-end.
Одним словом — OpenSource Splunk :)
Как я уже сказал, я совершенно не против виртуализации, но в случае моей инфраструктуры это не вариант по причине серьезных требований к производительности, к тому же данный пост покрывает установку на bare metal, что приходится делать, даже если есть виртуализированные среды.
>Это вы зря :)
Если зря — приношу извинения.
>Отлично работает, если изначально об этом подумать, виртуализация дает отличную масштабируемость и апдейт на новый сервер занимает считанные минуты(если просто замена железки, и диски виртуалок доступны для нового сервера изначально локально), достаточно развернуть гипервизор, и всё, тащи виртуалки туда и давай им больше ресурсов.
Все верно, но мир не идеален, и инфраструктуры переходят по наследству от инженера к инженеру, это тоже нужно понимать :)
>А я бы клонировал эталонную машину :)
Здесь не соглашусь, мое мнение по этому поводу — это лишает гибкости в дальнейшем. Эталонная машина — это еще одно «то» что нужно поддерживать и обновлять достаточно часто, а если начнут появляться требования в различии двух машин — еще чаще.
Господа хабравчане минусуют, но еще кроме Вас не отписался. Надеюсь все понимают, что пост — это часть одного большого целого об использовании системы управления конфигураций puppet в большой инфраструктуре, а не просто пост о том, как поставить винду :)
Позвольте немного уточнить мою позицию и расставить точки над «i» (наконец-то я не с телефона:))
Во-первых, iDrac никогда не заменит массовую установку через pxe. Представьте, у Вас под 200 серверов, возраст которых от 5 лет до нескольких месяцев. Изначалльно Dell не включал никакой iDrac в стандартную поставку, а сейчас включает только базовый вариант. Вам нужно обновить Windows на 10 из старых серверов. Что будет более эффективно, переставить ОС удаленно через pxe и WDS/kickstarter со всеми апдейтами или делать апгрейд сервера, устанавливая сначала iDrac, а потом монтируя ISO тысячалетней давности через сеть, устанавливая 1-2 сервера за раз, а потом полдня обновляя систему? Конечно iDrac мало пригоден в данном случае.
Во-вторых, изначально IP KVM — решение экономически более выгодное чем iDrac (сравните цены) + более гибкое (можно подключить куда угодно).
Не до конца понимаю как Вы видите мою инфраструктуру сидя за монитором, что беретесь судить о том, как «на деле»:
>На деле, парк из сотен физических серверов разносольным никто не делает
Вы почему-то рассматриваете инфраструктуру «с нуля» — только тогда есть возможность выбирать идеальное решение. К сожалению реалии жизни таковы, что работа инженера — это в первую очередь поддержка текущей инфраструктуры, и соответственно всего того, что делает деньги и что должно работать СЕЙЧАС, а уже потом ее улучшение. Возможно, если это унылый датацентр, где можно положить/переренести десяток сервисов — да, но не в моем случае.
Другая несостыковка — это не работает в среде стартапа, где темпы роста компании намного больше чем возможность оглянуться назад и сделать рефакторинг. Это роскошь, ведь те самые «первые» серверы обычно выполняют четко поставленные задачи. А дальше — рост, рост, рост. Хочется виртуализировать — некогда, нужно расти… Время бежит, модель сервера сменяется за моделью, и проект растет, и вот пора уже сервисы со старых серверов переносить — виртализировать? — нет, слишком медленно — поэтому и переносим. Сегодня картина несомненно улучшилась, и можно сделать выбор в пользу виртуализации для определенного круга сервисов, но здесь встает другой вопрос — инфраструктура уже существует и делает деньги, поэтому нужна миграция. Представьте, что у Вас высоконагруженный сайт с миллионом уникальных пользователей в день, где каждая минута простоя — тысячи $$$ упущенной выгоды. Выходит, что это перерастает в отдельный проект, который имеет свой приоритет перед другими задачами, а это уже совсем другая история. Ах да, рост, рост, рост. Понимаете о чем я? Да, все упирается во (время + деньги) = деньги ^ 2.
В-третьих, я продолжаю слышать нотки теории в Вашем комментарии. Все не так-то просто. Размещая 10 виртуалок на одном хосте Вы кладете «все яйца в одну корзину». В реальных условиях Ваши 10:1 превращается как минимум 10:2 + надежный и быстрый NAS + инфраструктура для надежной/быстрой передачи данных, а это, как минимум, 2x10Gb/s свитча стоимостью около $10 000. Все остальные конфигурации не отвечают нашим требованиям (медленно/ненадежно). Вы написали про «При определенных условиях уже можно кластер поднять» — для меня это единственное верное решение. Никаких условий для production среды нет — только так. К тому же со стороны сервиса надежность железного сервера выше чем надежность 10 виртуалок на 1м сервере, потому что на один сервис приходится один полностью, как минимум, вдвойне зарезервированный (redundant) сервер (CPU, Memory, PSU), в то время как в соотношении 10:1 на каждую виртуалку приходится только часть зарезервированного сервера, но я думаю это и так понятно что это означает.
В-четвертых, с чего Вы взяли что в моей боевой среде нужны «физически немощные сервачки»? — В реальности объем данных который обрабатывается огромен (в рамках данного сравнения), и использование виртуализации в такой системе не оправдано. Ну не заменить реальное железо и прямой доступ к IO в моем случае, никак не заменить, а с RAM — вообще беда (какой смысл слой виртуализации если 100% времени на хосте 1 виртуалка — удобство? Я лучше выберу производительность, так как именно она делает деньги. Делали тесты — знаем.
В-пятых, конечно, виртуализацию я люблю, и конечно мы ее используем, только с умом. Staging, Development и все что не требует больших ресурсов и 99.9% аптайма — все виртуализировано. OpenStack для разрабов, но там память у инстанса выставлена максимум 8GB, и это никто не использует…
Если бы сейчас мне предложили проект, который бы получил пользу от гибкости, где нужно было бы конфигурировать типовые машинки с небольшим количеством памяти и CPU — я бы с великой радостью все сделал виртуализированно НО все так же использовал бы PXE, так-как это удобно, гибко и быстро! Здесь исключение составят 100% клоны, где можно использовать шаблоны и снепшоты — вообще красота!
Еще раз повторюсь, я не идеалист, и решаю реальные проблемы в реальных ситуациях силами реальных людей и используя реальные деньги, а также реальное время. Может быть за это мне и платят реальными деньгами :)
Прошу прощения за сбивчивый русский, в России не живу уже 3 года.
Обычно такие рассуждения меня приводят к мыслям, что миру нужна система, которая была бы модульная, где модуль я могу написать сам, а другие придут из коммьюнити. Но ключевым должно быть то, что продукт должен быть достаточно user-friendly, чтобы его смогли использовать простые эникейщики. Поставил ядро, загрузил модули, указал пути (причем в GUI) — пользуйся. Я сравниваю с системой управления конфигурациями puppet, где такая же схема ядро/модули.
Сейчас для бекапа системы я использую софт из семейства Акронис.
Акронис не менее удобен для бекапов самих файлов — инкрементные бекапы (история файлов, соответственно), возможность подключить образ как диск, а также возможность хранить данные в облаке (FTP, S3, Acronis Cloud).
Также для Windows есть прекрасная программа goodsync, для Ваших нужд ее должно вполне хватить, на уровне файлов она работает точно так же как RSYNC, но имеет возможность также делать синхронизацию/бекап в облако. Программа хорошо поддерживается и постоянно развивается.
К сожалению никак не доходят руки до opensource проекта amanda backup, может кто пользовался? amanda.zmanda.com — система позволяет упорядочить все бекапы внутри инфрастрктуры (как заявляет сайт — аналог bacula с поддержкой более высокого уровня)
Выходит что при текущей загруженности моих человекочасов нужно попросту отключать ненужные проверки, до тех пор пока не возникнет потребность их мониторить…