Моя компания собирается приобрести другую компанию; мы запускаем стек LAMP, они запускают стек Microsoft. Мы не собираемся вечно запускать дублирующиеся инфраструктуры, скорее всего, мы перенесем их вещи в LAMP. Мы пытаемся определить лучший курс действий. Это достаточно зрелые сайты с высоким трафиком, размещенные в одном месте, наша команда не имеет опыта работы с MS, а их команда не имеет опыта работы с LAMP. Не пытаясь начать пламенную войну по поводу того, какая технология лучше, поэтому в качестве аргумента допустим, что мы собираемся перейти на LAMP.
Есть ли у кого-нибудь опыт миграции большой серверной инфраструктуры на базе Microsoft (MS Server, IIS, MSSQL, ASP.NET) на LAMP (Linux, Apache, MySQL, PHP)?
Как прошло? Какие были подводные камни? Любая информация будет полезна.
Перенос приложений с Windows на Linux будет стоить вам огромного состояния, и (на мой взгляд) вам вполне может быть лучше оставить все работающим на том, на чем оно сейчас работает.
Если вы переходите с ASP.net на PHP, вам понадобится разработчик, который может хорошо кодировать и то и другое, или вам понадобится разработчик ASP.net, пытающийся объяснить разработчику PHP, что делает каждая строка кода. . Лучше надеяться, что система ASP.net хорошо документирована, так как вам придется имитировать код на PHP. именно чтобы это работало должным образом (сюда также входят любые ошибки или странности в коде ASP.net).
Если платформа Windows будет обрабатывать данные (например, вызовы SOAP), вам придется чертовски протестировать это - если ASP.net вернул какие-то странные теги вместе с обычными тегами, вам придется закодировать PHP, чтобы вернуть Weirdo и теги - вы не знаете, что удаленные серверы делают с информацией.
Если в коде ASP.net использовались вещи, специфичные для SQL Server, у вас может возникнуть большая проблема, если вы не можете заставить MySQL имитировать функциональность SQL Server. В этом случае вы всегда можете заново спроектировать код, но это идет вразрез с тем, что я упомянул выше о точном переносе кода, и создает возможность возникновения незначительных ошибок.
До недавнего времени MySQL очень плохо поддерживала такие вещи, как триггеры и хранимые процедуры. Если SQL Server использует эти вещи, вы можете получить неожиданные результаты при запуске в MySQL.
Вам также нужно будет подумать о том, как вы выполняете резервное копирование MySQL - его возможности резервного копирования далеко не так хороши, как резервное копирование SQL Server. Я уверен, что у вас уже есть опыт резервного копирования ваших текущих баз данных MySQL, и это, вероятно, включает в себя резервное копирование подчиненных экземпляров ваших баз данных. Имейте это в виду, на всякий случай вам нужно купить больше подчиненных серверов MySQL.
Вам нужно будет посвятить МНОГО времени разработчика на это, а также время, необходимое для его тестирования и прохождения QA.
Кроме того, вы не упомянули, что происходит с текущей командой Windows. Если они будут сокращены, у вашего текущего персонала Linux внезапно возникнет нагрузка на дополнительные серверы и инфраструктуру для управления, и вам может потребоваться больше администраторов Linux или программистов PHP.
Если вы оставите тех, кто занимается Windows, им всем потребуется переподготовка в различных областях. Вам понадобится обучение администратора сервера Linux, обучение PHP и обучение MySQL. Я могу почти гарантировать, что по крайней мере один из них не обрадуется переходу на Linux, поэтому они либо будут жаловаться как сумасшедшие и превратят вашу жизнь в несчастье, либо уйдут. С Whinging сотрудниками никогда не бывает весело, но, к сожалению, ваша проблема :) Если они уйдут, вам придется нанять кого-то с необходимыми навыками.
При этом учитывайте своих пользователей. Если они добавили в закладки http://www.acme-widgets.com/Products.asp и это затем изменится на http://www.acme-widgets.com/Products.php вы сломали их закладку (расширение изменилось).
Есть какие-нибудь RSS-каналы? Теперь они все потенциально сломаны, потому что расширение изменилось.
Вам понадобятся правила mod_rewrite с некоторым описанием, чтобы переписать все .asp страниц в .php страниц.
При переносе данных с серверов Windows на серверы Linux неизбежно возникнут некоторые простои - это будет неудобно для пользователей, пока веб-сайт на базе Windows переключается на его аналог для Linux.
Поскольку вы приобретаете эту другую компанию, вы, вероятно, собираетесь (в конечном итоге, если не сразу) объединить их веб-сайт с вашим. Это также приведет к нарушению пользовательских закладок и ссылок, встроенных в Интернет, которые вы не можете контролировать. Опять же, убедитесь, что у вас есть соответствующие правила mod_rewrite.
Мигрируем два и из; постоянно кросс-платформенный, самым большим препятствием с точки зрения клиента является обеспечение того, чтобы все было запущено и работало, поскольку в критически важных приложениях возникает прерывание, когда начинается пожар.
Чтобы избежать этого шага, я бы первым делом определил архитектуру оборудования, что будет использоваться и где оно содержится. Оттуда посмотрите, есть ли какие-то вещи, которые вы используете с точки зрения миграции p2v, если это происходит в виртуальной машине и запускается параллельно от разработки к продукту, чтобы системы могли работать, пока у вас есть время для тестирования продукта.
Миграция базы данных должна быть гладкой операцией, если ваши администраторы баз данных знакомы с вещами, это будет самая легкая часть перехода.