Скоростной канал связи
Большинство наших клиентов – это крупные холдинги со своими большими IT-подразделениями. И за резервные копии информационных баз, как правило, отвечают специалисты клиента. Но имеются и относительно небольшие организации. Специально для них у нас есть услуга, согласно которой все вопросы, связанные с резервным копированием всего 1С-ного мы берем на себя. Про такую вот компанию и пойдет речь в данной истории.
Пришел новый клиент в поддержку 1С и, среди прочего, в договоре был пункт, что за резервные копии отвечаем мы, хотя в штате у них и был свой системный администратор. База клиент-серверная, в качестве СУБД – MS SQL. Довольно стандартная ситуация, но все же был один нюанс: основная база была достаточно большого размера, но при этом месячный прирост был совсем небольшим. То есть база содержала много исторических данных. Учитывая эту особенность, я настроил планы обслуживания резервного копирования следующим образом: в первую субботу каждого месяца делалась полная резервная копия, она была довольно увесистой, далее каждую ночь делалась разностная копия – относительно небольшого объема и каждый час копия журнала транзакций. Причем полные и разностные копии, мало того, что копировались на сетевой ресурс, так еще и дополнительно загружались на наш FTP-сервер. Это обязательное требование при оказании данной услуги.
Все это было успешно настроено, пущено в эксплуатацию и работало в общем то без сбоев.
Но несколько месяцев спустя в этой организации поменялся системный администратор. Новый сисадмин начал понемногу перестраивать IT-инфраструктуру компании в соответствии с современными веяниями. В частности, появилась виртуализация, дисковые полки, закрывался доступ везде и вся и т. д., что в общем случае, конечно, не может не радовать. Но не всегда у него все проходило гладко, часто были проблемы с работоспособностью 1С, что вызывало некоторые разногласия и непонимания с нашей поддержкой. Также, надо отметить, что отношения с ним у нас вообще сложились достаточно холодные и несколько натянутые, что только увеличивало градус напряженности в случае возникновения каких-то проблем.
Но вот как-то утром обнаружилось, что сервер этого клиента недоступен. Я позвонил системному администратору, чтобы узнать, что случилось и получил в качестве ответа что-то вроде «У нас сервер упал, работаем над этим, не до вас». Ну хорошо, что работают. Значит ситуация под контролем. После обеда перезваниваю снова, в голосе админа вместо раздражения уже чувствуется усталость и апатия. Пытаюсь прояснить, что же случилось, и можем ли мы как-то помочь? В результате разговора выяснилось следующее:
Он перенес сервер на новую систему хранения данных с только что собранным рейдом. Но что-то пошло не так и спустя несколько дней этот рейд благополучно рассыпался. Толи контроллер сгорел, толи с дисками что-то случилось, не помню уже точно, но вся информация оказалась безвозвратно утеряна. А главное заключалось в том, что сетевой ресурс с бэкапами тоже в процессе всяких миграций оказался на этом же дисковом массиве. То есть была утеряна как сама продуктивная база, так и все ее резервные копии. И что теперь делать, непонятно.
Спокойно, говорю. У нас есть ваш ночной бэкап. В ответ - тишина, по которой я понимаю, что только что спас человеку жизнь. Начинаем обговаривать, как перекинуть эту копию на новый, только что развернутый сервер. Но и тут возникла проблема.
Помните, я говорил, что полная резервная копия была довольно большого размера? Я не зря делал ее раз в месяц по субботам. Дело в том, что компания представляла из себя небольшой завод, который находился далеко за городом и интернет у них был сильно так себе. К утру понедельника, то есть за выходные, эта копия с горем пополам успевала прогрузиться к нам на FTP-сервер. Но ждать день-два пока она загрузится в обратную сторону возможности не было. После нескольких неудачных попыток перетянуть файл, админ вынул жесткий диск прямого из нового сервера, нашел где-то машину с водителем и быстренько помчался к нам в офис, благо находимся мы все же в одном городе.
Пока стояли у нас в серверной и ждали, когда файлы скопируются, мы впервые познакомились, так сказать, «вживую», выпили по чашке кофе, пообщались в неформальной обстановке. Я посочувствовал его горю и с полным винтом бэкапов отправил назад, спешно восстанавливать остановившуюся работу компании.
В последующем, все наши заявки в IT-отдел решались очень оперативно и разногласий более не возникало.
Обратитесь к вашему системному администратору
Как-то раз у одного клиента я очень долго не мог опубликовать 1С для веб-доступа через IIS. Вроде бы рядовая задача, но вот тут никак не выходило все запустить. Подключились местные системные администраторы, пробовали разные настройки и конфигурационные файлы. 1С в вебе нормально не хотела работать ни в какую. Что-то было не так толи с доменными политиками безопасности, толи местным замудренным файрволом, или еще с черт знает чем. На N-ой итерации админ скидывает мне ссылку со словами:
- Попробуй еще раз по этой вот инструкции. Там все довольно подробно расписано. Если не получится, напиши автору этого сайта, может он поможет.
- Нет, - говорю, - не поможет.
- Почему?
- Я и есть автор этого сайта… :(
В итоге без особых проблем запустили на Apache. IIS победить так и не смогли.
На уровень глубже
Был у нас клиент – небольшое производственное предприятие. Был у них сервер, такая своеобразная «классика» 3 в 1: сервер терминалов + сервер приложений + сервер баз данных. Работали они в некоторой отраслевой конфигурации на базе УПП, пользователей было в районе 15-20, производительность системы в принципе всех устраивала.
Шло время, все работало более-менее стабильно. Но вот Европа ввела против России санкции, вследствие чего Россияне начали покупать преимущественно продукты отечественного производства, и дела у этой компании резко пошли в гору. Количество пользователей выросло до 50-60 человек, открылся новый филиал, соответственно вырос и документооборот. И вот уже текущий сервер перестал справляться с резко возросшей нагрузкой, и 1С начала, что называется, «тормозить». В часы пиковой нагрузки документы проводились по несколько минут, сыпались ошибки блокировок, долго открывались формы, ну и весь прочий букет сопутствующих услуг. Местный системный администратор отмахивался от всех проблем, мол «Это ваша 1С, вы и разбирайтесь». Мы неоднократно предлагали провести аудит системы на производительность, но до самого аудита так дело и не дошло. Клиент просто попросил дать рекомендации по устранению проблем.
Ну я сел и написал довольно объемное письмо о том, что необходимо разделить роли терминального сервера и сервера приложений с СУБД (что, в принципе, ранее уже неоднократно нами и так говорилось). Написал про DFSS на терминальных серверах, про Shared Memory, накидал ссылок на авторитетные источники и даже предложил некоторые варианты по оборудованию. Это письмо дошло до власть имущих в компании, спустилось назад в IT-отдел с резолюций «Выполнять» и лед в общем то тронулся.
Спустя какое-то время админ присылает мне айпишник нового сервера и учетные данные для входа. Говорит, что MS SQL и компоненты сервера 1С там развернуты, и надо перенести базы, но пока только на сервер СУБД, так как возникли какие-то проблемы с ключами 1С.
Зашел, действительно, запущены все службы, сервер не очень мощный, ну ладно, думаю, лучше, чем ничего. Перенесу пока базы данных, чтобы хоть как-то разгрузить текущий сервер. В обговоренное время выполнил все переносы, но ситуация не изменилась – все те же проблемы производительности. Странно, конечно, ну что ж, зарегистрируем базы в кластере 1С, там посмотрим.
Проходит несколько дней, ключи так и не перенесены. Интересуюсь, в чем проблема, вроде бы там все просто – вынул из одного сервера, воткнул в другой, поставил драйвер и готово. Админ в ответ юлит, говорит что-то про проброс портов, виртуальный сервер и прочее.
Хм… Виртуальный сервер? Вроде бы никогда никакой виртуализации и них не было... Вспоминаю про довольно известную проблему с невозможностью проброса серверного ключа 1С в виртуальную машину на Hyper-V в Windows Server 2008. И тут у меня начинают закладываться некоторые подозрения…
Открываю диспетчер сервера – Роли – появилась новая роль - Hyper-V. Захожу в диспетчер Hyper-V, вижу одну виртуальную машину, подключаюсь… И действительно… Наш новый сервер баз данных…
Ну а что? Указания начальства и мои рекомендации выполнены, роли разнесены. Задачу можно закрывать.
Спустя некоторое время случился теперь уже кризис, новый филиал пришлось закрыть, нагрузка снизилась, производительность системы стала более-менее сносной.
Ну а серверный ключ, конечно же, пробросить в виртуальную машину так и не смогли. В результате все как есть и оставили: сервер терминалов + кластер 1С на физической машине, сервер баз данных там же в виртуальной.
И ладно бы была это какая-нибудь шарашкина контора. Так нет. Известная компания, продукцию которой вы наверняка знаете и видели в соответствующих отделах всяких Лент и Ашанов.
График отпусков жестких дисков
Один крупный холдинг с амбиционными планами захватить мир в очередной раз купил небольшую компанию с целью включить ее в свою мегакорпорацию. Во всех подразделениях этого холдинга пользователи работают в своих базах, но с идентичной конфигурацией. И вот у нас начался небольшой проект по включению нового подразделения в эту систему.
Прежде всего необходимо развернуть продуктивную и тестовые базы. Разработчик получил данные для подключения, заходит на сервер, видит установленный MS SQL, сервер 1С, видит 2 логических диска: диск «С» на 250 гигабайт и диск «D» объемом 1 терабайт. Ну «C» - это система, «D» для данных, логично решает разработчик и разворачивает все базы именно там. Даже планы обслуживания, включая резервное копирование, на всякий случай настроил (хоть мы за это и не отвечаем). Правда бэкапы складывались здесь же на «D». В дальнейшем планировалось перенастроить уже на какой-нибудь отдельный сетевой ресурс.
Проект стартовал, консультанты провели обучение по работе в новой системе, были перенесены остатки, выполнены какие-то небольшие точечные доработки и пользователи начали работать уже в новой информационной базе.
Все шло хорошо, пока однажды утром в понедельник не обнаружилось, что диск с базами данных пропал. Просто нет «D» на сервере и все.
Дальнейшее расследование выявило вот что: на самом деле этот «сервер» был рабочим компьютером местного системного администратора. Правда стояла на нем все же серверная ОС. В сервер был воткнут личный USB-диск этого админа. И вот администратор уехал в отпуск прихватив с собой и свой винт, с целью накачать на него фильмов в дорогу.
Слава Богу файлы баз данных он удалить не успел и продуктивную базу удалось восстановить.
Примечательно то, что всех, в общем то, устраивала производительность системы, расположенной на USB-диске. На какую-то неудовлетворительную работу 1С никто не жаловался. Это уже позднее в холдинге начался мегапроект по переносу всех информационных баз на единую централизованную площадку с супер-серверами, СХД за миллион+ рублей, навороченными гипервизорами и невыносимыми тормозами 1С во всех филиалах.
Но это уже совсем другая история…
P. S. Смотрите также:
- Байки разработчика №1: детективные
- Байки разработчика №2: эпикофейлические
- Байки разработчика №3: страшные истории...
- Байки разработчика №4: админские
