Недавно я получил дополнительную работу по переносу веб-сайта с виртуального хостинга на VPS. Сайт работает на Django + Apache (mod_wsgi) + MySQL. Текущий хост работает под управлением CentOS 5.6 (32-разрядная версия); стоит ли мне воспользоваться переходом на CentOS 6? И, учитывая выбор между 32-битной или 64-битной CentOS, следует ли мне придерживаться 32-битной версии или перейти на 64-битную?
(У меня больше опыта в разработке, чем в сисадминах, отсюда и мой вопрос. Я также знаю Debian / Ubuntu намного лучше, чем CentOS, но я хотел бы познакомиться с CentOS, и это довольно несложная установка, чтобы получить начал с.)
Есть несколько плюсов и минусов:
5.x против 6.x
Ваш новый провайдер действительно поддерживает CentOS 6.0 прямо сейчас? Например, Rackspace Cloud обещает только «скоро» поддержку Centos 6.0, прямо сейчас вам придется начать с 5.6.
Вы цените более свежие пакеты или вам нужно поддерживать устаревшее программное обеспечение, особенно с закрытым исходным кодом, созданное для версии 5.x? Если вам не нужно поддерживать старое программное обеспечение, я бы посоветовал начать использовать более новую версию.
Знаете ли вы, что нет пути обновления с 5.x до 6.x? Например. вам придется выполнить полную переустановку, если вы устанавливаете 5.x сейчас, а 6.x потребуется позже.
32-битная или 64-битная
Что поддерживает ваш хостинг? Некоторые предоставляют только 64-битные или только 32-битные поддерживаемые платформы? Например. некоторые облачные инстансы Amazon только 32-битные, а облачные инстансы Rackspace - только 64-битные.
Вообще говоря, 64-разрядная система требует больше ОЗУ для выполнения той же работы, что и 32-разрядная система. Однако он также может поддерживать и эффективно управлять большим объемом памяти. Если вы планируете сервер на 4 ГБ или больше, то лучше всего использовать 64-разрядную версию. С другой стороны, если на вашем сервере будет 2 ГБ памяти, вам действительно не понадобится 64-разрядная версия, а 32-разрядная система будет управлять существующей памятью с меньшими потерями.
До тех пор, пока вы сохраняете возможность «вернуться к работе после сбоя» на заведомо исправном сервере на старом сайте, это стоящий способ выполнять обновления.
Два года назад мы переместили целый центр обработки данных, выполнив поэтапное преобразование всех серверов в P2V. Работали как чемпион, и у нас была возможность вернуться к старому физическому серверу на старом сайте, если что-то пошло не так.
Имейте под рукой план тестирования, чтобы убедиться, что все действительно работает правильно на новом сайте, прежде чем переключать какие-либо переключатели (DNS).