Здравствуйте.
У меня сейчас все скрипты крутятся на отдельном компьютере с Win XP с выделенным каналом в интернет. В последнее время стала падать надежность данного решения и я хочу арендовать виртуальный сервер с Windows server 2008. Хотел бы узнать будет ли нормально работать TSLab на Server 2008 и если будет работать, то сколько заказывать оперативки 512 или 1024Мб (в данный момент одновременно работают 3-5 скриптов на 5 минутках)?

А в чем profit виртуального сервера? Как вы изверяли "падение надежности"?

Все равно в TSLab нету встроенного автоматического failover.

То есть любая из ошибок типа: проблема с интернетом, проблема с железом, проблема с брокером приведет к неработоспособности программы. Каким образом здесь поможет вирт. сервер Windows server 2008 - не понятно.

У меня есть ряд workarounds, которые помогают мне в случае чего быть в курсе проблем и быстро наладить работу, но это не полноценное решение.

Скрипты крутятся вообще в виртуалке winxp на linux. Регулярно делают snapshots рабочей системы(весь вирт. диск целиком). Поэтому я могу быстро заменить весь образ ос. Это будет даже быстрее, чем восстанавливать данные из backup tslab. И плюс это спасает от проблем с самой ос.
Snapshot копируются регулярно на другой физ. диск.
Дублирующий интернет канал мне пока не нужен, но прикрутить его не сложно опять же на стороне host-системы(на которой крутится виртуальный windows).
В планах сделать еще оповещалку. Если tslab не сделают возможность получать уведовления о том, что "все сломалось", то сделаю что-то свое на основе анализа логов.

Чего я бы хотел от tslab в плане надежности.

1. Сделать оповещения о том, что данные не приходят в течении определенного времени, нету связи с сервером и так далее для critical ошибок.

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

3. Автоматический failover. Должна быть возможность активировать копию программы, находящейся на другом копьютере автоматически по какому-либо событию. Естественно, что между копиями должна быть репликация данных типа master-slave.

С автоматическим переходом на другой сервер не все так просто.
Например в Финаме уже сейчас существует кластер серверов, поэтому при реконекте после сбоя вы можете попасть на уже другой сервер. Между ними осуществляется синхронизация по текущим данным, но как показывает опыт есть ньюансы. Не тем более если переключится на резервный сервер, может получится что на нем нет последней информации по активным заявкам.
На Алоре каждый сервер сам по себе, и если у вас есть учетка на одном сервере, не факт что получится подключится к другому.
Оповещения при обрыве коннекта и сейчас уже есть (событие с номером 2), можно пользоваться.

Оповещения при обрыве коннекта и сейчас уже есть (событие с номером 2), можно пользоваться.

нужно чтобы оповещение шло в скайп или майл, а не только в проге, по крайней мере этого хочется.

В почту уже сейчас оповещения идут, в скайп насколько я знаю нет открытого API, поэтому проблематично.
Уже сейчас в большой тройке операторов есть работающие шлюзы mail-sms.
Но в целом согласен, пока дальнейшее развитие оповещения застопорилось, пока в приоритете более важные вещи. Надеюсь к версии 1.2 сможем порадовать в этой части.

Ну по-поводу репликации и failover мы уже с вами это обсуждали в другом топике. Понятное дело, что она асинхронная. Но можно придумать какой-то вариант, если не на стороне брокера, тогда на стороне TSlab. Это была бы killer-feature на самом деле, потому что насколько мне известно у ваших конкурентов в России такого нет.

хорошо, буду разбираться с оповещениями на почту.

Без всякой иронии, какие продукты по ВАШЕМУ мнению являются конкурентами TSLab ? Если позволяет время распишите за счет какого функционала. С уважением.

andy, может быть я не прав, но вы получаете деньги, если человек торгует через TSlab на реальном счету(абонентка + хостинг). Поэтому с моей точки зрения упор должен делаться прежде всего на фичи для людей которые торгуют, а не на тех, которые моделируют и тестируют. А для реальной эксплуатации важна прежде всего надежность, потому что потерять профит от счета с миллионом рублей и больше по причине глюка очень и очень неприятно. Поэтому здесь, мне интересно сравнивать ваше решение с другими продуктами именно как платформами для торговли. Ну вот например я могу на stock# написать failover для некоторого класса ошибок. Например, могу в случае если брокер не доступен, переключиться на другого. Могу управлять данными более гибко. В общем много чего могу. Естественно за такую гибкость приходится платить известную цену. Мне кажется что TSlab должен развиваться в сторону гибкости, не теряя при этом своих лучших качеств. Можно, например, открывать и более низкоуровневые вещи в API для реализации разработчиком на свой страх и риск.

Все предложения по форуму, с поддержки, и тд нами обработаны. Расписаны приоритеты и ушли в работу.

Готовится версия 1.2. Где будет много функционала, который требует Клиент.

Далее будет очередной период обработки новых фич и разработка. Разработка софта - это бесконечный процесс.

Тем Клиентам, которые доросли и им не хватает существующего функционала, берут TSLab API и работают на C#. Кому и этого мало, видимо им уже не нужен TSLab, они решают свои задачи самостоятельно. По моему все логично ?

Немного конкретики добавлю.

- failover
Мысль хорошая и здравая. Но в 1001 раз. Проблема в том, скрипты знают о своих заявках-сделках по примечанию на клиенте TSLab, не на сервере. Чтобы легко "ложить" один TSLab и тут же в моменте подхватывать другой TSLab со всей текущей ситуацией, то необходимо комментарии хранить на стороне сервера. Мы естественно хотели от брокеров чтобы эта информация была на их серверах, но для этого им надо чуть напрячься и реализовать это, что в условиях России почти невозможно :-)

- авто переподкючение

=Например, могу в случае если брокер не доступен, переключиться на другого

Какой в этом смысл ?
У вас есть инфраструктура, которая "на лету" перекидывает средства с одного брокера на другой ? :-)

Переподкючение внутри брокера по серверам смысл имеет. Это надо понимать как устроена работа у каждого конкретного брокера. Опять же упираемся в конкретную реализацию серверной части.

Я вас уверяю, что вы со stock# получите все те же проблемы что и мы. Мы просто в более выгодном положении. У нас есть доступ к разработчикам серверных частей. И мы реализуем только то, то возможно с той или иной архитектурой брокера.

При появлении своей серверной части все эти вопросы будут учтены :-) Спасибо за мысли. Но они нам не новы.

По моему я довольно широко раскрыл вопрос. Давайте на этом закончим :-)

Я про сложности в курсе.

>Какой в этом смысл ?
У вас есть инфраструктура, которая "на лету" перекидывает средства с одного брокера на другой ? :-)

Хотя бы вывести позицию в нейтральную, начиная с точки отказа.

Почему сейчас не сделать хотя бы возможность того, чтобы человек мог повесить свой обработчик на такую ситуацию. Это же сделать элементарно. Сейчас, если вы не за компьютером вообще ничего сделать нельзя, только понадеятся на авось.

"понадеятся на авось"

Этого делать не стоит.

В данный момент есть Паркинг. На нем все крутится. Вы имеете доступ с iPad или НетБук через Yota + Скайлинк + 3G Мегафон-Билайн-МТС. Этот доступ всегда с вами.

Есть Менеджер уведомлений, который мы будем развивать дальше.

Этих инструментов достаточно чтобы перекрывать 99 процентов проблем. Не надумана ли проблема с вашей стороны ?

Ок. Какой у вас SLA на паркинг и на какие проблемы он распрастраняется?

Возьмите тестовый доступ на неделю.
Сами все увидите и пощупаете.