Байки разработчика №4: админские

Публикация № 967886

Сообщество - О жизни

Байки разработчика Системный администратор Бэкапы

46
Все разработчики 1С так или иначе тесно взаимодействуют с IT-службами и непосредственно с системными администраторами. Но не всегда это взаимодействие проходит гладко. Несколько забавных историй об этом я бы и хотел рассказать вам сегодня.

Скоростной канал связи

Большинство наших клиентов – это крупные холдинги со своими большими 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. Смотрите также:

 

46

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. Shmell 256 21.12.18 12:06 Сейчас в теме
Виталя, слушай, прям читается легко и примеры из жизни стоящие ) .
1v7; demkonst; ABudnikov; wowik; +4 Ответить
4. Tavalik 2065 21.12.18 14:09 Сейчас в теме
2. AlX0id 21.12.18 12:50 Сейчас в теме
Примечательно то, что всех, в общем то, устраивала производительность системы, расположенной на USB-диске.

Вот тут вот прям поржал )
9. vermouth 23.12.18 10:01 Сейчас в теме
3. ResAndDev 21.12.18 13:46 Сейчас в теме
А что, тот сисадмин не знал, чем грозит хранение баз на таком диске и последующее отключение этого диска ?
5. Tavalik 2065 21.12.18 14:09 Сейчас в теме
6. PerlAmutor 45 21.12.18 19:14 Сейчас в теме
Напоминает нашу историю. Год мучились с тормозами, и оптимизировали все что могли в 1С и ТЖ разбирали и счетчики ставили. Причину тормозов найти не удалось. Приняли решение покупать новый сервер. Еще пол года его покупали, еще пару месяцев нам его доставляли, еще пару месяцев его меняли, так как доставленный был с дефектом. В итоге - наши сисадмины отщипнули небольшой кусочек от всех его мощностей, подняли виртуалку (Hyper-V) и развернули на ней сервер 1С. Необъяснимые тормоза базы прекратились. Производительность стала стабильной, стабильно такой же какой и была, но без необъяснимых тормозов. Все мои попытки уговорить руководство перенести 1С на физическую машину с виртуалки не увенчались успехом. Мол зачем это надо, если и так более менее работает... Зато теперь приходится следить за потребляемой 1С оперативной памятью и местом на жестком диске. Чаще перезапускать рабочие процессы и контролировать сделались ли бэкапы.
7. triviumfan 10 22.12.18 12:02 Сейчас в теме
(6)
Зато теперь приходится следить за потребляемой 1С оперативной памятью и местом на жестком диске. Чаще перезапускать рабочие процессы и контролировать сделались ли бэкапы

И как это связано с тем, что 1с на хосте или виртуалке?
8. PerlAmutor 45 22.12.18 22:16 Сейчас в теме
(7) На хосте все ресурсы, а на виртуалке лишь маленький их кусочек, так как админ зарезал все в несколько раз. Чем заняты другие ресурсы сервера купленного под 1С одному админу известно.
10. acanta 63 23.12.18 15:50 Сейчас в теме
Из наших. Программисты 1с (переученные бухгалтера). Первый раз столкнулись с SQL, никаких Studio в глаза не видели, о том что нужны какие-то пароли вообще не слышали никогда. Бакапы делаем в конфигураторе "выгрузить данные", и ругаемся, что это такое хваленые американские системы даже бакап нормально сделать нельзя.
Есть рабочая база, есть какая-то "копия разработчика" у меня компе, полупустая, в DBF (7ка). Порядка 30 пользователей. Что-то там случается с сервером, админ тоже мальчик для ношения картриджей. Сколько времени уйдет у него на то, чтобы разбраться непонятно. Восстанавливается бакап часа 4 или 5 и восстанавливать его некуда, поскольку продуктивный сервер один и он на тех.обслуживании. Отгрузка круглосуточная, завод.
Девочки-программисты перебрасывают заказы и отгрузку на свежую периферийную от тестовой базы (локальная сеть, тормоза, отгрузка в одном здании, заказы в другом, разные подсети, как сделать на одну базу не знаю), и пускаем всех кому срочно. С бухгалтерией частично договариваемся, что они подождут пока не сделаем. И отгрузки идут как обычно. Позже все что набрано перебрасываем в рабочую базу, которая таки восстанавливается.
11. 1c_nik923 23.12.18 17:39 Сейчас в теме
Улыбнула история с USB-диском )) Не плохо пишите, продолжайте!
12. PerlAmutor 45 23.12.18 18:45 Сейчас в теме
На днях была странная ситуация. Утром у всех пользователей, у которых была доменная авторизация стало всплывать окно авторизации с предложением ввести логин и пароль. И какие бы настройки не менял пользователю - ничего не менялось. Так как на днях делали обновление конфигурации с доработками сделанными фирмой франчайзи - стали подозревать их. Попросил администратора запустить cmd.exe от имени других пользователей на сервере, где работает агент сервера 1С, проблем не было. Но именно 1С авторизацию не пропускал. Уже настроились на разворачивание бэкапов и перенос нескольких сотен документов...После перезагрузки сервера вход через доменную авторизацию нормализовался. Что это было до сих пор непонятно.
13. namazi74 2 23.12.18 21:33 Сейчас в теме
в голосе админа вместо раздражения уже чувствуется усталость и апатия

аж сердце кольнуло. бэкапы надо проверить...
14. Stim213 363 28.12.18 10:19 Сейчас в теме
вот тоже из жизни:

Небольшая контора, перестал работать обмен между УТ и БП. Как выяснилось потом - данные в БП не загружались тупо из-за установленной даты запрета редактирования. Мне разбираться было некогда, выгрузил базы, залил к себе на облако и отключился с целью посмотреть проблему спокойно в выходные.
Буквально через дня 3 вся контора ловит шифрующий вирус, который накрывает все базы. Бекапов разумеется, они не делают.
Звонят, плачут в трубку. А у меня - бекапы и относительно свежие. Смотрели как на спасителя.
Надеюсь, сейчас настроили бекапы.
Оставьте свое сообщение