Погода: -12°C
  • Э... Не многовато? Ведь, всего 20 пользователей...

  • В ответ на: Э... Не многовато? Ведь, всего 20 пользователей...
    ну немного ошибся, сумма будет ниже, примерно получается все так: 2х процессорный сервер HP с 4 винтами 500gb+8Gb+raid примерно выходит $3500 если добавить виндовс 2008 на 25 клиентов, то общая сумма за один комплект возрастет до $7100, еще UPS нужен будет нормальный...

    Да, мое замечание по задаче - при таких объемах я бы базы разделил, одна основная крутится на одном серваке, а текущие документы вводятся на втором и регулярно за определенный период, например сутки-двое, данные из "оперативной" базы переносятся в основную :миг:ну это как вариант:улыб:

    Вне ассоциаций, вне конкуренции...

  • Я в своих прикидках стоимость ПО не учел. Тогда да, скорее всего, соглашусь с первой цифрой.

  • ни о каких серваках по 250 тыр речи быть не может... все гораздо дешевле и оптимистичнее. и ни в коем случае не соглашайтесь на "две базы" - геморроя получите выше крыши.

    п.3

  • Какие надо сервера?
    Этот вопрос задавайте внедренцам. На официальном бланке предприятия.
    Вы хотите у форума проект по железу получить? Так что-ли?

    Ну нарисуют Вам конфигурацию, Вы с ней к директору придёте "вот мне тут на форуме насоветовали"? Возьмёте на себя такую ответственность?

    "колоссальные потери"... если руководству предприятия понятны цифры потерь за час/сутки и т.д., то проблем с понимаем сумм на реализацию проекта быть не должно.

    На Ваше "рас" - занимайте более чёткую и последоваательную позицию перед руководством такого плана:
    "Я считаю, что рекомендованная конфигурация не сможет обеспечить нужные нам .... Для реализации поставленных задач требуется то-то...." и служебкой директору.

    на Ваше "два"
    никаких проблем с технической точки зрения не вижу. Тут писали, что не нужно две базы. Смотря как подходить к решению задачи.
    Должна одна база для продажников, бухгалтеров -тех кто работает с вводом/выводом первички.
    И копия базы - например ежедневно "поднимаемая" из бэкап на другом серваке, с которой будут "играться" экономисты и аналитики. Чтобы при запуске расчётов не "пригружать" производительность основной системы.

    А если смотерьть на конфигурации FaceOFF - с таким количеством "шпинделей" Вы не получите достойной производительности дисковой системы.
    А вот сколько - вопрос к "внедренцам", которые исходя из своего опыта выполнения подобных проектов могут дать рекомендации. Читаем первый абзац.

    Но я уже повторяюсь.

  • В ответ на: "колоссальные потери"... если руководству предприятия понятны цифры потерь за час/сутки и т.д., то проблем с понимаем сумм на реализацию проекта быть не должно.

    никаких проблем с технической точки зрения не вижу. Тут писали, что не нужно две базы. Смотря как подходить к решению задачи.
    Должна одна база для продажников, бухгалтеров -тех кто работает с вводом/выводом первички.
    И копия базы - например ежедневно "поднимаемая" из бэкап на другом серваке, с которой будут "играться" экономисты и аналитики. Чтобы при запуске расчётов не "пригружать" производительность основной системы.
    Соглашусь. Особенно с разделением баз. Только грамотно настроить, и проблем с обменами не будет.

  • Базы с таким небольшим, в общем-то, документооборотом прекрасно работают и без "разделения"...

  • В ответ на: А если смотерьть на конфигурации FaceOFF - с таким количеством "шпинделей" Вы не получите достойной производительности дисковой системы.
    А вот сколько - вопрос к "внедренцам", которые исходя из своего опыта выполнения подобных проектов могут дать рекомендации. Читаем первый абзац.
    Но я уже повторяюсь.
    Через меня прошло столько скомплектованных/ сконфигурированных серверов за последние лет 10 - Вам даже не снилось... я привел примерную конфигурацию, в конкретику на тему как и что будет сконфигурировано даже не вдавался, дабы не учить некоторых представителей контор псевдо-внедренцев...
    И как можно оценивать производительность системы, не зная как она сконфигурирована :dnknow:
    Так что не надо ля-ля...если есть конкретные спорные моменты - озвучьте, только в привате - не хочу здесь размещать инфу...
    По поводу проектов по железу и софту - я не скрываю, что оказываю по комплексной автоматизации и если мы заключаем договор письменный или устный с заказчиком, то естественно я ему предоставляю полную смету с аргументацией что надо, как и почему...
    А чуть выше по поводу количества жестких дисков, их вообще пять шт. надо.. почему столько - советую поучить мат.часть по организации рейд-массивов:улыб:

    Вне ассоциаций, вне конкуренции...

  • В ответ на: Базы с таким небольшим, в общем-то, документооборотом прекрасно работают и без "разделения"...
    да, конечно, но разделение баз (как они должны правильно взаимодействовать я расписывать здесь не хочу по той же причине, какая озвуче чуть выше по железу) позволит обеспечить достаточную отказоустойчивость системы, так как при таком объему ввода документов даже простой в течение 6-12 часов тянет за собой большие убытки...

    Вне ассоциаций, вне конкуренции...

  • Пипец. За мой 14 лет в ИТ тоже дохрена проектов было и что? Пиписьками мериться будем?

    А по поводу организации RAID советую Вам матчасть подучить.


    RAID 0 - min 2 spindel
    RAID 1 - min 2 spindel
    RAID 5 - min 3 spindel
    RAID 10 - min 4 spindel

    http://en.wikipedia.org/wiki/RAID

  • В ответ на: Пипец. За мой 14 лет в ИТ тоже дохрена проектов было и что? Пиписьками мериться будем?
    en.wikipedia.org/wiki/RAID
    Мериться с вами не собираюсь, все написал выше,
    а Вы продолжайте вводить в заблуждение народ дальше... и Вам на будущее - не стОит давать народу ссылки на подобные ресурсы - там некорректной информации в разы больше чем правды...

    Вне ассоциаций, вне конкуренции...

  • господа а вы про кластеризацию не забыли? такой документоборот не редкость, да проблемы могут быть - это если не продумать сразу, но все решается и с большим документооборотом. Главное здесь что скорость записи не подкаала. Если уж совсем плохо - то можно сделать так называемое "частичное" проведение. Но повторюсь решабельно и на отличную оценку.

  • ТС говорил, что "сторадж" брать не собираются. Скорость записи - под вопросом. Либо сервак с большой внутренней полкой брать, шпинделей на 10 и "вперёд с песней".

    при грамотном планировании и без кластеризации прожить можно.

    "мутная" какая-то ситуация, поднятая ТС. То колоссальные потери, то 10 человек на документах, то "денег не хотим каждый год платить на расширение" при это и сразу "вложиться" не могут толком спланировать.

  • п.9
    про стораж даже намека нет. я говорил о кластеризации 1С и СУБД. И если не большой секрет откройте тайну как грамотное планирование на кластеризацию влияет

    Исправлено пользователем Barlog (21.08.09 14:11)

  • рассказываю:
    грамотно запланировав нужные конфигурации оборудования, для работы спецуального программного обеспечения, закупили енто оборудование. оборудование обеспечивает требуемую для бизнеса доступность в режиме 24х7х365 на протяжении 6 лет. Без кластеризации.
    До данным логов доступность от 99,99, до 99,9. Ибо серверов несколько и спецуального программного обеспечения - несколько.
    Бизнес - доволен.
    И без дополнительных вложений в это оборудование на протяжении 6 лет.

    Грамотное планирование повлияло на кластеризацию. Её нет.

  • вы говорите о кластеризации железной:улыб:
    а я про кластеризацию програмную, причем не виртуализацию.
    Если организовать кластер серверов 1С предприятия то и так называемого "планирования" нет:улыб:
    Но согласен что стоит обдуманно и к железному вопросу подходить.

  • Ну много разных технологий существует.
    Зачем усложнять проект?
    Тем более, что дискуссия ушла куда-то в сторону. И ТС отмалчивается.

  • п.9 Если честно это только упрощает:улыб:и действительно для кого это мы :а\?:

    Исправлено пользователем Barlog (21.08.09 14:12)

  • Посмотрел я на сайте 1С пример внедрений. Определённо у организации ТС проблемы с пониманием задач и реализацией проекта. Ни у кого таких объёмов нет.
    Как размера базы, так и кол-ва документов. Что-то в бизнес-процессах организации не так.

    Картинка в аттаче.

  • А Вам не приходит в голову, что есть более крупные предприятия, чем киоски на рынках? Предприятия, в которых 4 000 отгрузок в день - это норма?
    Уж извините за резкость...

  • Аттач-то смотрели? или так "постебаться"

    На первой строке Аконит.
    это млять ларёк что-ли?
    С максимальным чилсом пользователей 370?
    А размеров базы 174 Гига.
    http://v8.1c.ru/overview/techparams/akonit.htm

    Резкий Вы наш.

    Рассмешили.

  • Тогда я несколько не понял Вашего предыдущего поста. ТС заявляет гораздо меньший документооборот.

  • В ответ на: Доброе время суток. народ подскажите не кто не сталкивался с переходом с SQL на DB2. Или возможно кто-нибудь тестировал данное ПО. Интересует прежде всего насколько лучше или хуже работает связка db2 c 1c по сравнению с SQL c 1c.
    Вот свежак от 1С:БИТ внедрение на DB2 . причем там бесплатная версия, которая 2 Гб памяти всего использует. У вас пользователей сколько? Возьмите workgroup - она до 16 гигабайт оперативки уже испольует и посмотрите что и как. Берете триал версии 9.7 с сайта IBM и вперед. Только db2set DB2_WORKLOAD=1C не забудьте после инсталляции сделать:улыб:

  • Мы проводили замеры, по которым можно сказать, что для документооборота 200 000 док/мес (1000 док/час) в 1С 8.1 (УПП) вполне может хватить и бесплатной DB2 Express-C, особенно если речь идет об оперативной работе.

  • А можете описать, как Вы производили эти замеры?
    Мои тесты, например, показали, что типовая УТ под скулем тихо мирно сдувается уже на первой сотне тысяч документов.

Записей на странице:

Перейти в форум

Модераторы: