а) Он: менеджер, MS Excel для нас рулит, на OOCalс до сих пор смотреть не можем
б) Она(то есть, я) UNIX-администратор.
Мягкая сила(рассказы про годовые аптаймы, работу под нагрузкой, и т д) vs грубой силы (будет все по-моему!)
В результате он где-то год тому назад перелез на Mandriva мне назло (я пару раз о ней не очень хорошо отзывалась, но в серверном контексте), хотя до этого пытался меня злить разговорами про то, что везде будет стоять самая «инновационная Vista» :)))
Теперь для него Windows и порносерфинг не совместимы, а для Office использует Virtual Box, а для 1c терминал в виртуалку на сервере, и, вроде бы, доволен :)
Извиняюсь, что-то в релизах запуталась: они не так часто бывают, в сравнении с Ubuntu и Fedora, а тут и RHEL 6 бета, и RHEL 5.5, и, наконец, CentOS 5.5, а пока единственного клиента с RHEL мы не планируем переводить на шестую ветку (и в RHN не видела, что там не доступны те же iso-ки)
В Virtuozzo Parallels Containers и OpenVZ живая миграция между нодами вообще без стораджей с начала двухтысячных, но это не виртуализация, а контейнеры(очень хорошая альтернатива виртуализации для Linux-only серверной инфраструктуры, что часто может встречаться в крупных web-проектах вроде социальных сетей и пр. стартапах, но редко в офисах).
У RedHat KVM скоро появится аналог Storafe Vmotion (точнее, уже есть в Fedora 13, но использовать Fedora в production себе дороже, а когда это будет в RHEL/CentOS пока не ясно).
У остальных, Xen от Цитрикса и свободный от RH и Novell, Parallels Hypervisor, Hyper-V ничего такого и не предполагается, тоже поправьте, плиз, если не права…
> Вы про HA? Я пока не использую кластер. Но уже задумываюсь. для CIFS шар XFS, для iSCSI — iSCSI.
Уверена, это опечатка, и Вы в курсе, но, наверное, имели ввиду GFS, OCFS, или multipath(хотя и это тоже не ФС)? Ведь iscsi это не ФС :)
Для виртуализации это нужно только если используются тормозные image-based виртуалки на общем сторадже с одной ФС, но вообще применяется, когда нужен блочный доступ с нескольких машин к одному девайсу…
Хотела бы так же отметить, что стоит собирать gmirror на слайсах, слайсы делать некоего усредненного размера, заведомо меньшего, чем объем любого диска коммерческого «размера» (не секрет, что часто даже у одного вендора диски 72 Gb и/или терабайт на самом деле разного размера, и разной геометрии )
Профит в том, что софт-зеркало можно собирать из винтов разных вендоров (или разных серий одного вендора).
На линухе тоже самое: в md стоит вставлять не sda и sdb, a sda1 и sdb1 нормализованного значения: теряете считанные гигабайты, а зато экономите себе и нервы, и деньги на запас самых разных ЗИП :)
ECC память часто требует специализированных комплектующих(CPU, материнка), что Европейские ДЦ, предлагающие дешевые серверы-десктопны, себе могут позволить далеко не всегда…
Вот именно серверные комплектующие и стоят дороже. А так да, если уже подбираешь что-нибудь клиенту на Intel/Supermicro в 1u корпус из готовой платформы, финансового смысла брать не ECC нет.
Хотела бы без дальнейших холиваров, на которых не хватит кармы(так как новенькая), ответить на Ваши вопросы :)
Плюсы CentOS (RHEL):
1. Время поддержки: на тот же PHP ветки 5.1 _всегда_ в течение семи лет будут выпускаться патчи безопасности, при этом то, что ветки ПО старые, это не баг, а фича: делается все для сохранения API, что бы Вам, при поддержке своего web-приложения не пришлось переписывать его радикально.
Да, то что тот же Питон старый, многим не нравится, но, опять же, это фича, и этот питон будет поддерживаться до 2014-го года
2. Стек приложений: CentOS/RHEL платформа это не только система + репозитории, это еще и подход в чем-то похожий на подход MS (и плохо это или хорошо, это отдельный вопрос), например, в этом стеке тот же LVS и Cluster Suite для кластеров. Debian-way все ставить из репозиториев, а RH-way, выбирать правильные инструменты для решения задачи :)
3. Удобство управления, развертывания и автоматизации. Да, тот же Puppet запросто прикручивается и к Debian и к Ubuntu, но тут, в Anaconda kickstart, Cobbler (мы им через интернет ставим серверы клиентам с помощью VirtualMedia), Spacewalk/Sattelite/RHN возникает упорное ощущение того, что для красивого, быстрого и удобного deployment'а делается очень и очень много(в сравнении с другими платформами), если не все
4. Бэкпорты последних фич в стабильные ветки, без слома совместимости: не смотрите на ядро 2.6.18 (кстати, вообще-то уже вышел RHEL 6, так что 5-я ветка уже несколько устарела)
Делается многое, что бы, например, проприетарный драйвер на raid-массив сервера, установленный через rpm, не сломался при обновлении ядра(хотя, на самом деле, все равно бывает)
При всем этом, объем патчей в RHEL-ветке 2.6.18 таков, что сравнивать его с ванильным 2.6.18 совсем не корректно
5. rpm-пакеты, я их очень люблю за то, что собираются проще и удобнее (спек сам по себе вообще сказка), чем deb. Речь не о пакетном менеджере(!) yum vs {apt,aptitude}, а именно о пакетах.
>когда пришлось настраивать CentOS на продакшене, хотя все девелоперы кодили на Ubuntu и тестили на >нем же
Наверное, в этом и было дело: все-таки это _разные_ платформы, и разрабатывать изначально нужно было под ту платформу, под которой и предполагалось работать, согласны? Все-таки неправильно обвинять производителя сервера с корзинами hotswap под 2.5 диски, что он, такой буржуй окаянный, не дает ставить 3,5'' диски, разве не так?
«А компилить и искать по репам» это не RH-way, окажись я на Вашем месте, при таких требованиях ПО, написанного разработчиками, никогда бы не ставила что-то кроме Debian/Ubuntu LTS (из личных предпочтений, скорее, Debian)
> Да и Ubuntu Desktop вполне стабильна. Времена 8.xx, когда apt-get update вырубал нафиг иксы ушли,
Наверное, apt-get upgrade? yum, конечно, немного более опасный инструмент, чем apt, но yum check-update тоже вряд ли у кого-то приводили к катастрофе, да и приоритеты по репозиториям рулят, как и чтение центосной вики :)
Может быть, кому-нибудь полезно будет: под Linux VirtualBOX очень удобно жестко лимитировать с помощью утилиты cpulimit:
============================================
Name: cpulimit Relocations: (not relocatable)
Version: 1.1 Vendor: (none)
Release: 8.fc12 Build Date: Чтв 01 Апр 2010 00:03:20
Install Date: Чтв 01 Апр 2010 00:03:40 Build Host: localhost
Group: Applications/System Source RPM: cpulimit-1.1-8.fc12.src.rpm
Size: 12904 License: GPLv2
Signature: (none)
URL: cpulimit.sourceforge.net
Summary: CPU Usage Limiter for Linux
Description:
cpulimit is a simple program that attempts to limit the cpu
usage of a process (expressed in percentage, not in cpu time).
This is useful to control batch jobs, when you don't want them
to eat too much cpu. It does not act on the nice value or other
scheduling priority stuff, but on the real cpu usage.Also, it is
able to adapt itself to the overall system load, dynamically and quickly.
==========================
Для десктопов-ноутов очень удобно :) Для серверов, конечно, не на столько (тот же KVM лучше использовать с Cgroups, хотя в RHEL/CentOS 5 Cgroups, увы, нет)
Принцип утилиты основан на том, что она часто-часто посылает процессу сигналы sigstop и sigcount
а) Он: менеджер, MS Excel для нас рулит, на OOCalс до сих пор смотреть не можем
б) Она(то есть, я) UNIX-администратор.
Мягкая сила(рассказы про годовые аптаймы, работу под нагрузкой, и т д) vs грубой силы (будет все по-моему!)
В результате он где-то год тому назад перелез на Mandriva мне назло (я пару раз о ней не очень хорошо отзывалась, но в серверном контексте), хотя до этого пытался меня злить разговорами про то, что везде будет стоять самая «инновационная Vista» :)))
Теперь для него Windows и
порносерфинг не совместимы, а для Office использует Virtual Box, а для 1c терминал в виртуалку на сервере, и, вроде бы, доволен :)Sattelite и Fedora не очень сочетаются :)
Вот только (имхо) большинство юзеров такие системы не использует.
Libvirt это проект RedHat, причем сейчас они перестали делать ставку на эту библиотеку (в RHEV она не используется)
У RedHat KVM скоро появится аналог Storafe Vmotion (точнее, уже есть в Fedora 13, но использовать Fedora в production себе дороже, а когда это будет в RHEL/CentOS пока не ясно).
У остальных, Xen от Цитрикса и свободный от RH и Novell, Parallels Hypervisor, Hyper-V ничего такого и не предполагается, тоже поправьте, плиз, если не права…
На OpenNet было интересное обсуждение: www.opennet.ru/openforum/vsluhforumID3/36804.html
В котором дискутировавшие согласислись, в итоге, что AoE нельзя применять в критичных к сбоям системах.
Уверена, это опечатка, и Вы в курсе, но, наверное, имели ввиду GFS, OCFS, или multipath(хотя и это тоже не ФС)? Ведь iscsi это не ФС :)
Для виртуализации это нужно только если используются тормозные image-based виртуалки на общем сторадже с одной ФС, но вообще применяется, когда нужен блочный доступ с нескольких машин к одному девайсу…
Профит в том, что софт-зеркало можно собирать из винтов разных вендоров (или разных серий одного вендора).
На линухе тоже самое: в md стоит вставлять не sda и sdb, a sda1 и sdb1 нормализованного значения: теряете считанные гигабайты, а зато экономите себе и нервы, и деньги на запас самых разных ЗИП :)
Вот именно серверные комплектующие и стоят дороже. А так да, если уже подбираешь что-нибудь клиенту на Intel/Supermicro в 1u корпус из готовой платформы, финансового смысла брать не ECC нет.
Мы собираемся взять сервер (вместо keyweb) в Serverloft только из-за ECC-памяти
Плюсы CentOS (RHEL):
1. Время поддержки: на тот же PHP ветки 5.1 _всегда_ в течение семи лет будут выпускаться патчи безопасности, при этом то, что ветки ПО старые, это не баг, а фича: делается все для сохранения API, что бы Вам, при поддержке своего web-приложения не пришлось переписывать его радикально.
Да, то что тот же Питон старый, многим не нравится, но, опять же, это фича, и этот питон будет поддерживаться до 2014-го года
2. Стек приложений: CentOS/RHEL платформа это не только система + репозитории, это еще и подход в чем-то похожий на подход MS (и плохо это или хорошо, это отдельный вопрос), например, в этом стеке тот же LVS и Cluster Suite для кластеров. Debian-way все ставить из репозиториев, а RH-way, выбирать правильные инструменты для решения задачи :)
3. Удобство управления, развертывания и автоматизации. Да, тот же Puppet запросто прикручивается и к Debian и к Ubuntu, но тут, в Anaconda kickstart, Cobbler (мы им через интернет ставим серверы клиентам с помощью VirtualMedia), Spacewalk/Sattelite/RHN возникает упорное ощущение того, что для красивого, быстрого и удобного deployment'а делается очень и очень много(в сравнении с другими платформами), если не все
4. Бэкпорты последних фич в стабильные ветки, без слома совместимости: не смотрите на ядро 2.6.18 (кстати, вообще-то уже вышел RHEL 6, так что 5-я ветка уже несколько устарела)
Делается многое, что бы, например, проприетарный драйвер на raid-массив сервера, установленный через rpm, не сломался при обновлении ядра(хотя, на самом деле, все равно бывает)
При всем этом, объем патчей в RHEL-ветке 2.6.18 таков, что сравнивать его с ванильным 2.6.18 совсем не корректно
5. rpm-пакеты, я их очень люблю за то, что собираются проще и удобнее (спек сам по себе вообще сказка), чем deb. Речь не о пакетном менеджере(!) yum vs {apt,aptitude}, а именно о пакетах.
>когда пришлось настраивать CentOS на продакшене, хотя все девелоперы кодили на Ubuntu и тестили на >нем же
Наверное, в этом и было дело: все-таки это _разные_ платформы, и разрабатывать изначально нужно было под ту платформу, под которой и предполагалось работать, согласны? Все-таки неправильно обвинять производителя сервера с корзинами hotswap под 2.5 диски, что он, такой буржуй окаянный, не дает ставить 3,5'' диски, разве не так?
«А компилить и искать по репам» это не RH-way, окажись я на Вашем месте, при таких требованиях ПО, написанного разработчиками, никогда бы не ставила что-то кроме Debian/Ubuntu LTS (из личных предпочтений, скорее, Debian)
> Да и Ubuntu Desktop вполне стабильна. Времена 8.xx, когда apt-get update вырубал нафиг иксы ушли,
Наверное, apt-get upgrade? yum, конечно, немного более опасный инструмент, чем apt, но yum check-update тоже вряд ли у кого-то приводили к катастрофе, да и приоритеты по репозиториям рулят, как и чтение центосной вики :)
Нам еще очень интересны улучшения в KVM, и заявленная поддержка Magny-Cours
============================================
Name: cpulimit Relocations: (not relocatable)
Version: 1.1 Vendor: (none)
Release: 8.fc12 Build Date: Чтв 01 Апр 2010 00:03:20
Install Date: Чтв 01 Апр 2010 00:03:40 Build Host: localhost
Group: Applications/System Source RPM: cpulimit-1.1-8.fc12.src.rpm
Size: 12904 License: GPLv2
Signature: (none)
URL: cpulimit.sourceforge.net
Summary: CPU Usage Limiter for Linux
Description:
cpulimit is a simple program that attempts to limit the cpu
usage of a process (expressed in percentage, not in cpu time).
This is useful to control batch jobs, when you don't want them
to eat too much cpu. It does not act on the nice value or other
scheduling priority stuff, but on the real cpu usage.Also, it is
able to adapt itself to the overall system load, dynamically and quickly.
==========================
Находим нужную нам виртуалку:
ps aux | grep -i freebsd | grep -v grep
500 5199 52.1 8.2 1402904 211488? Sl 20:00 4:22 /usr/lib/virtualbox/VirtualBox --comment FreeBSD --startvm 282d7bd1-5131-4b6b-9e8c-eb704aa5e031
И лимитируем процесс с пидом 5199 на 8 процентов cpu, при завершении процесса (-z) завершаем cpulimit:
sudo cpulimit -p 5199 -l 8 -z &
[1] 5872
[shaggycat@desktop2 ~]$ Process 5199 detected
Для десктопов-ноутов очень удобно :) Для серверов, конечно, не на столько (тот же KVM лучше использовать с Cgroups, хотя в RHEL/CentOS 5 Cgroups, увы, нет)
Принцип утилиты основан на том, что она часто-часто посылает процессу сигналы sigstop и sigcount