Виртуализация 1с7/8 #686744

Почитал-почитал по всему интернету, но решения для себя так и не нашел. Суть вопроса: 0) В одной организации имеются две организации. Которые то женются, то разводятся - очевидно зависит от времени года и противостояния планет. а) Имеются 4 сервера на е5-2620 (6 ядерные зверьки) со 128Гб мозга на 1.7ТБ raid 10 (4х1Тб), с 4х1G сетевухами, на каждом поднят Hyper-V б) К ним имеется 4 Qnap (459/469) c  raid5 2.7Гб (4x1Тб) каждый. в) Свичи и прочее - всё 1Гбит В настоящий момент под Hyper-V на одном сервере крутится десяток всяких мелочей (PDC, web, mail и т.п.), еще на двух крутится под Hyper-V по паре SQL: для 1С8.х и для 1C7.7  - каждая пара для своей организации. Qnap'ы создают видимость своего использования как бакапы по iSCSI Лицензий на софт (что MS, что 1С) - 3-кратный запас. Теперь вопрос. Хочется что-то сделать. :) Текущее желание таково: сложить все виртуалки SQL 1С на один сервер - т.е. все 4 виртуалки на одном железе. 1) либо сделать кластер из 2 нодов с кунапом 2) либо просто положить на один, а второй сделать Hyper-V репликой. Какой путь может посоветовать сообщество? Волнует именно проблема: потянет ли qnap в виде кластерного ресурса 4 SQL для 1С? И вообще потянет ли 1 такой мой сервер 4 таких виртуалки без суровых тормозов? Сразу скажу: "объединять" SQL и ставить на "чистое жедезо" - не вариант вообще. Мне Hyper-V уже нравится даже больше, чем женщины.

4 SQL на 4х виртуалках которые крутятся на одной железяке ? гы гы гы гы

зачем что-то делать, если судя по всему оно и так неплохо работает? для двух организаций некислая структурка

> Хочется что-то сделать женись

Я бы тоже посмеялся, если бы не: Сейчас при 2х SQL-виртуалках на одном железе в пиковый момент рабочего дня: 0.14% vCPU on lCPU 45% - очереди дисков (все) 30% - загрузка HpvCPU 15% - загрузка физических CPU Т.е. железо задействовано ни на что. Сервак с "мутью" - 12 виртуалок (линуксы с виндами в перемешку) - загрузка 44%

Так в том-то и дело, что: бакапы тупо SQL сейчас. Т.е. падение рейда - и начинаются развертывания виртуалок и накатывание бакапов. я этого не хочу - я один одмин, мои сотрудники - программеры. Таким образом, хочется сделать именно избыточность с резервированием. Кластер кажется глупым, т.к. к нему надо все одно делать реплику, ибо падения nas - это ппц. А просто делать реплику - значит все на одну машину. Иначе получается 100% избыточность - а это слишком даже для меня...

Автор занят самолюбованием

был бы занят - не писал бы. На самом деле вопрос серьезный и я его думаю уже 3 день. И никак не могу ни найти решения, ни сам решить: на западных форумах не юзают достаточно кривую в SQL реализации 1C, а на наших трепах - либо более дорогие SAN (не nas), либо софтовые iscsi на линухах, либо 1-2 сервера. Т.е. по факту у меня в теории  есть избыточность, а на практике есть неопределенность. Почему сюда и залез.

надо ждать, наговоритесь с ним до посинения на эти темы

Видать придется ждать. ((

Ты, главное, про число пользователей и количество/объем баз никому не говори, тогда точно до посинения пыхтеть будете

Вообще, конечно, анекдот про солнце по теме ветки очень актуален

А что за анекдот? Кстати, по-ходу дела, решение нашлось Вот правильно в детстве говорили: не можешь осознать в полной мере - напиши, нарисуй или просто расскажи. :) Пока здесь переписывался, то по-ходу и пришел к выводу (наверное самому оптимальному). Число пользователей - всего 200 штук, баз - до дури (включая тестовые, пробные, косячные и развлекательноэкпериментальные - что-то около 5-7 бд на скул-сервак, каждая по 20 гб) Поскольку с процами и мозгами всего хватает, то вопрос так и остался - в носителе. Рисковать с 1с на кунапах все же не буду (кривизна реализации и того и другого может плачевно кончиться), потому еще раз посмотрел стату: по физическому диску по каждому серваку с двумя скулами-1с, стата показывает 5% очереди, около 1-4мс латенси (0,004 макс.), т.е. в три раза ниже предельно допустимой нормы. А потому, и чтобы не мучать излишне диски, пока сделаю так: 2 основных сервака с текущими парами скулов сделаю репликами друг-друга. А два других загоню в кластер с репликами машин на первые два сервака (кластерных машин много, но  все мелкие - по 30-40гб vhdx) Каналы все 1G и, разумеется, поделены подсетями и "во избежание" виланами. Вобщем как-то так. Какие мысли может есть еще у кого?

Мизантроп прав.

Скуль на виртуалке - ню-ню (особенно если это 2005) А зачем 4 скуля, почему не рулить инстансами?

+1

нарциссизм — весьма тяжелое и трудно корректируемое расстройство личности

+2 за Мизантропа виртуализация ради виртуализации, системное администрирование ради чсв админа

+2 всем поддерживающим мнение ставлю композицию Homesick Parov Stelar

про 4 скуля ответ изначально из структуры: 1. две организации, которые то женятся, то разводятся, вплоть до переездов. 2. Не инстансами, потому-как 1с7.7 со своими фечами и прочими через задний проход написанными курсорами отвратительно себя ведет под скул 2012 и терпимо под 2005, а 8.2 отлично себя ведет под 2012, который не менее отлично себя ведет под hpv вин серв 2012. 3. ну а всем прочим и по всему прочему отвечу статой с 8 утра до 12:41 (юзеров сидит по 15 голов во всех четырех серваках): (средний, минимум, максимум) 1) Логический диск Среднее время записи на диск, с (0.004, 0.000, 0.024) - допустимый предел 0.025 область максимума  достигнута 2 раза за 5 часов б) Логический диск Среднее время чтения с диска, с (0.005, 0.000, 0.017) - допустимый предел 0.025 в) Физический диск Среднее время записи на диск, с (0.002, 0.000, 0.016) - допустимый предел 0.025 г) физический диск Среднее время чтения с диска, с (0.005, 0.000, 0.032) - допустимый предел 0.025 область максимума  достигнута 1 раз за 5 часов д) Память Обмен страниц/с (0.240, 0.000, 89.59) е) сетевой интерфейс, длина очереди вывода (0.000, 0.000, 0.000) - допустимый предел 1 ж) логический процессор - не более 4.5%  гостевой работы и общего времени работы Таким образом наблюдаю лишь пиковые затыки в дисках. Т.е. надо ловить - кто и как в SQL грузит диск. И сразу вопрос: поскольку я от 1с далек как заяц от триппера. Есть ли какие-либо средства мониторинга действий 1С на SQL? Или пользоваться средствами SQL ?

предлагаю увековечить    blairvss в золоте.. как истиного гуру SQL и возвести его на пьедестал потеснив маню и завсома.

Ок, Floody и   Мизантроп. Ваше решение для ситуации: 2 организации, в каждой 2 мощных сервака под вин2012 с двумя Qnap, не считая файловых серваков (по два в каждой) и не считая серваков "обеспечения" (в одной 3, в другой 2) с серверами 1с-8, всякими спецориентированными софтинами и т.п. Обе работают в 1С 7.7 и 8.х И любая из них в любой момент времени может со своим шкафом и активной стойкой переехать в любое здание в черте города, как уже бывало. Но. Данные частично общие и подгружаемые либо туда, либо туда в зависимости от типа. Оставлять железо в одном месте ни одна организация не может. Связь при переездах обеспечивается оптикой и/или дальнобойным WiFi по крышам (до 25 км) Ваше решение, "не нарциссы" и "не чсв админы"? С удовольствием бы принял к сведению какое-либо решение, для оперативной миграции железа и софта без HPV.

что такое "сервера обеспечения"  - подтягивают из тыла пакеты? снабжают сервера  которые "на передовой" новым пингами и свежими портами ?

> для оперативной миграции железа и софта без HPV HPV — Human Papillomavirus, Папилломавирус человека. Эти вирусы — одни из самых распространенных. По некоторым оценкам, до 60% и более людей являются их носителями. Известно более 100 видов ВПЧ. Из них более 40 — могут вызвать поражение аногенитального тракта (половые органы и анальное отверстие) мужчин и женщин и появление остроконечных кондилом.

ну ептыть, что ты как маленький.. сделай 4 виртуалки на одной железке.. вторая выклчена и ждет переезда да, будет работать как гамно.. но это плата за потенциальную возможность съехать в любой момент (хотя ни разу не видел переезда где у админа не было бы пары суток на подготовку и выгрузку нужных данных) опять же - какой бы быстрый не был бы переезд - выгрузить фулбекап с общего суля на флешку и потом загрузить его на новом месте в новый сервак - занимает 10 минут..

+ причем то время которое ты потратишь на остановку и копирование виртуального сервера на нужную железку можно так же потратить и на выгрузку фулбекапа из общего единственного скуля и загрузку его в нужный сервер..  ито это будет быстрее..

придумывают какую то куету блин.. дали игрушку - вируталки.. все бл.ять.. теепреь каждой уборщице свою виртуалку со скулем.. совсем е.анулись..

"Сервера обеспечения" - да, вроде как из тыла пакеты :)) Это VoIP сервера и шлюзы, всякие сервера 1С-8 (серверные части на старом железе, которое выкинуть жалко), зеркала файловиков и файлопомойки, всякие NetFlow, IPFlow и т.п.   " ну ептыть, что ты как маленький.. сделай 4 виртуалки на одной железке.. вторая выклчена и ждет переезда " Вот об этом и поднят вопрос изначально. :))) И ничто никуда не выгружается - железо тоже переезжает.

я бы делал так: один боевой скуль с 4мя базами. надо переехать -выгрузил фулбекап и загрузил на том сервере куда переезжают. нет таких переездов офисов в которых у админа нет суток на то чтобы включить поднять и загрузить все данны причем если сервак сделан заранее -то время переезда базы будет равно времени загрукки SQL базы из полного бекапа..

Ты почти угадал про уборщицу :)) Согласно нашим ФЗ многие вещи должны быть именно на всем своем , да еще и виланы не всегда принимаются, как разграничения. Еще раз: железо тоже переезжает. нету понятия выгрузил/загрузил: не встречал я носителей в 8Тб, чтоб все выгрузить и загрузить.

Мизантроп, не поверишь: Hyper-V и HPV имеют очень много общего, а сфера и прочие попытки виртуализации с HPV - вообще суть одно и то же. ))

каки 8 тб у тебя 7ка на 8 ТБ? ты определись: если вы просто переезжаете то порядок действия такой: 1. выключил сервер в старом офисе 2. погрузил в тачку 3. привез в новый офис 4. включил сервер в новом офисе какие блин виртуалки? Если вы разъезжаетесь то серверов всяко два, старый что остался и новый что появился в новом офисе. порядок действия следующий: 1. на старом сервере в базе делается полный бекап 2. бекап копируется на носитель 3. носитель грузится в тачку 4. тачка приезжает  в новый офис 5. носитель подключается к новому серверу 6. база восстанавливается из бекапа если новый сервер собирают в старом офисе и он оттуда едет - никто не мешает полный бекап сразу на диски нового сервера выгрузить и увезти новый сервер. еще раз -каким раком тут виртуалки?

такой продвинутый админ и не знает про бекапы ? зы: хочешь место сэкономить выгрузи средствами 1С в dt  или zip (если 7ка) выгрузку.. и твои 8 тб плавно превратяться в 2 гб..

админы б.ть.. пивом их не пои, дай виртуалок нахреначить на каждый самый мелкий сервис...

ты клоун

лучше быть иногда клоуном - жить веселее. И иногда лучше пить, чем говорить. да мутно всё это: туда сюда грузить, бэкапить. Я уже привык, что все делается или софтом или моим личным софтом, но все равно софтом... Не получается убрать затыки на логическом диске. Уже, мамкина норка, кластера поднял и туда отправил  - qnap не вытягивает, хоть и линукс там. Open iSCSI под нормальным линуксом на нормальном серваке - тоже не тянет - уже на адаптерах затык. А может и правда, парни, вывести SQL из Hyper-V? Только, ***, запарно заставлять работать 7.7 под скул2012... фечи из неё не убрать, а 2012 на них плюется, шо ппц.... Счас буду пробовать.

> Счас буду пробовать. Воскресенье, работают рабы

бекап ты выгружать не софтом будешь а возьмешь кайло и спустившись в шахту будешь вырубать из гранита? чо за бред то?

смирись уже.. в твоей гамноконторе нужны знания начинающего админа которые умеет выгружать бекапы.. не надо за них придумывать мегасложные условия для революционных решений которых нет.. твою мегавиртуозность и богатый жизенный виртуальный опыт тут применять не надо.. так что ты подобен гонщику формулы 1 которого отправили за хлебом через дорогу..   и теперь гонщик спрашивает маршрут где можно до 300км/ч разогнаться а так же советов как проходить повороты и где удобнее и быстрее питстопы.. когда достаточно просто перейти по подземному переходу на другую сторону улицы слушая радио...

если в воскресенье работают рабы, то должны работать и погонщики рабов... не ?

не катит. ( Простой не допустим вообще. Даже в выходные сидят бабенки, работают: кто локально, кто удаленно (несколько даже с египта торчат). Ладно, думаю тему можно закрывать. Никто здесь с подобным не сталкивался, а те, кто вообще сталкивались - у них бюджеты позволяют поднимать SAN и не париться. Все, всем спасибо, всем удачи.

как ты перевезшь 50 бабенок из одного офиса в другой без простоя? чушь то не пори.. а по времени выгрузка на внешний носитель виртуального диска или выгрузка на внешний носитель бекапа скуля занимает сопоставимое время, да и то - скуль быстрее выгрузить

с египта торчат.. кто то из туалета, кто то из сауны, кто то с египта.. сразу вспоминается старый бородатый анек  ".. вот и сейчас.. извини за неровный подчерк"

На днях админ попросил перенести скл на новый сервер, но, что он там навертуализировал не  сказал! мания у них такая - похер, что одна железка.

как-как? Отцепил кандалы в одном месте, загнал всех в газенваген, вручил ноутбуки, и пусть колотят, пока едут. На новом месте прицепил кандалы на место

ну вообще оно примерно так. только не ноуты, а планшеты - с ними меньше гемора :)

Планшеты? Может тогда уж айфоны

Вобщем в качестве небольшого завершения, мало ли кому-то поможет. Точнее тому, кому было изначально лень (как и мне) искать и листать англицкий мануал на тичнете майкрософта. Ну и заодно для тех, кто " 4 SQL на 4х виртуалках которые крутятся на одной железяке ? гы гы гы гы ". Итак: ось - win2012srvstd, скул - sql2012std 1 база в среднем 5 Гб Сервер 1 2хе5-2620 (6 ядров) со 128Гб мозга на 1.7ТБ raid 10 (4х1Тб), с 4х1G сетевухами. скул 2012, разумеется, видит 24 цпу, ибо процы с ht. 2хraid-1 - системный + логи в 1ТБ; файло данных + темп-дб в 1ТБ Варианты: 1 инстанс скула с 8 базами, и 4 инстанса скулов с 2 базами Сервер 2 2хе5-2620 (6 ядров) со 128Гб мозга на 1.7ТБ raid 10 (4х1Тб), с 4х1G сетевухами, Hyper-V, 4 VM  = х 16gb ram x 4cpu x 1 ide vhd x 1 scsi vhd Сервер 3 (по итогам тичнетовского BP SQL in Hyper-V) = Сервер 2, +  vhd = passthr. Краткий результ : по итогам системного монитора и тулзов с SQLIO Сервер 1 "быстрее" Сервера 2 на: storage ~ max 10%, overall - 5% oper. ~ max 3%, overall - 0% cpu util. ~ max 5%, overall - 2% Сервер 3 "быстрее" Сервера 2 на: storage ~ max 7%, overall - 2% oper. ~ max 0%, overall - 0% cpu util. ~ max 0%, overall - 0% Таким образом, свои вопросы и хотелки закрыл кластером из двух узлов под мелочевку и мелкие SQL, и 4 скулами под Hyper-V на одном хосте с репликами на второй хост. А, да, еще в довесок: каждая сетевуха смотрит в свою сеть - юзерам, одмину, сану и iscsi. Так-что как-то, тем кто спорил и думал - циферки, гаденыши, тичнет подтверждают....

а, да, забыл вписать выше: именно когда самая ние****ая база 1с-7.7 в 20гб тормознула сторадж почти на 30% (латенси вырос до 0.6 и я о**ел), то это вылечилось банальным залитием в VM двух виртуальных scsi дисков по 30 GB : один тупо под неё, другой под её логи. И все стало мило и легко, даже любимые 7.7 феч-курсоры забирают 10% времени проца, а на "физике" - 30%.