У нас есть перегруженный сервер, на котором сейчас работает один экземпляр SQL Server 2000 на физическом оборудовании, и около 40 различных приложений взаимодействуют с ним ежедневно. В прошлом году RAID-контроллер вышел из строя, и у нас не было запасного, поэтому ИТ-служба поддержки быстро перенесла его в копию, работающую на сервере VMWare. Пока он был на этом сервере, все работало намного быстрее из-за значительного улучшения характеристик. Однако в самом большом приложении, использующем его, время от времени возникали серьезные ошибки, которые никогда не возникали на физическом оборудовании.
В частности, несколько раз в неделю он отключал группы пользователей - от десяти до сотен одновременно, и всех одновременно. Это не повлияло ни на каких конкретных пользователей, ПК или офисы - все пострадали в равной степени.
Единственным распространенным явлением было приложение, которое представляет собой приложение VB6, использующее для подключения ADO 2.8. Другие приложения, подключающиеся к этому виртуализированному экземпляру SQL Server, по-видимому, не имели проблем, хотя они (и несут) ответственность только за небольшую часть работы, связанной с этим сервером.
В результате примерно через две недели любви к скорости и ненависти к случайным массовым отключениям (которым мы так и не смогли найти причину) мы, к сожалению, приняли решение вернуться к физическому оборудованию, и отключения исчезли.
Теперь мы достигли точки, когда старый сервер просто не может справиться со всем, что от него требуется, и мы собираемся перенести все на 2 или более других сервера. Загвоздка в том, что есть большая вероятность, что им снова придется быть виртуальными. Учитывая то, что произошло в прошлый раз, я пытаюсь выяснить, какие возможные причины могли быть для этих массовых отключений. Мы использовали VMWare ESX, но сеть построена на базе Novell. Кроме того, на сервере была настроена связанная серверная установка для подключения к серверу Informix с использованием заведомо ошибочного драйвера ODBC, который используется в течение дня.
Есть идеи по поводу причин?
Я нашел это исправление, которое может быть вашей проблемой. Вам нужно будет сделать это на виртуальной машине SQL. Сетевое соединение имеет параметр "Разгрузка задачи", который вызывает проблему. Вот сообщение, в котором описывается исправление.
[http://forum.wegotserved.com/index.php?/topic/11433-help-my-network-connection-keeps-dropping-out/]
View PostReg, 22 января 2010 г. - 12:08, сказал: «Ну, возможно, я решил проблему с сетевым подключением». Основываясь на том, что я прочитал на форуме резервного копирования, я отключил «разгрузку задачи», расположенную в расширенных настройках моей карты сетевого контроллера. С того времени (около недели назад) я смог успешно создать резервную копию моего компьютера с Win 7 без потери сетевого подключения. Я понятия не имею, что означает «разгрузка задачи».
Я сделал то же самое и начал резервное копирование вручную для одного из клиентов Windows 7. Резервное копирование только что успешно завершилось без каких-либо проблем, и я очень счастлив.
Я тоже не знал, что это за «Разгрузка задачи», поэтому я поискал его в Интернете и нашел объяснение в Википедии. Кажется, это протокол, который разбивает большие куски данных на более мелкие фрагменты, прежде чем они могут быть отправлены по сети ... http: //en.wikipedia....segment_offload Может быть, кто-то из вас понимает это лучше, чем я, поскольку я не очень разбираюсь в компьютерах или сетях.
Проверьте журналы ошибок и тому подобное. Звучит так, как будто это может быть большое замораживание ввода-вывода - что-то было заменено (или виртуальная машина начала менять местами), чего, вероятно, не должно было быть, и потребовалось так много времени, чтобы вернуть его обратно под нагрузкой, что все просто сломалось.
Ваши виртуальные машины меняются местами? Это смерть производительности на любой платформе виртуализации.