?

Log in

Эльфожурнал Below are the 10 most recent journal entries recorded in the "Эльфийское лицо" journal:

[<< Previous 10 entries]

Май 29, 2017
11:06 am
(перепостил angry_elf)
[my_xcalibur]
[reposted post]

[Ссылка]

А ты уже прочел "Конфедерацию Меганезия"?
Алоха! Итак, это что-то вроде мини-презентации нашей чудесной интеллектуальной тусовки, собравшейся вокруг цикла романов Александра Розова - "Конфедерация Меганезия". Для начала, как и обещал - картиночка, во многом отражающая смысл происходящего:

Меганезия Хартия Розов

Новость: на нашем создающемся форуме, новый администратор - angry_elf - теперь-то всё точно будет круто!
А вот всякие ссылки по теме Меганезии (там книги Розова и пр., в общем, для забаненных на Google в самый раз).
Также, рекомендую прочитать чудесный креатив sisterlee насчет идейной и функциональной основы нашего меганезийского сообщества.
Остальное - выразим в каментах.
И да, фоа, пожалуйста понажимайте нижерасположенные кнопочки для перепоста. О смысле сего действа я уже писал позавчера в нашем сообществе. Спасибо!

(12 комментариев | Оставить комментарий)

Сентябрь 22, 2016
09:17 am

[Ссылка]

Нашел себе хороший VPS в неведомых далях
Рекламы псот.




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

Минутка ненависти к Амазону.
Бесплатные инстансы и траф амазона в итоге обошлись мне в $20 за неполный месяц. Потому что один инстанс мои апликации не потянул, пришлось брать второй, а он уже не бесплатный. Инстанс с базой почти постоянно был в угнетённом режиме (амазон честно пиздил половину процессорного времени), диск там тупил адски, хоть и обещанный ssd.
База, причем, даже не mysql, а православный couchdb.

К слову, режим "честного процессора" в амазоне - свинство и ад. Выглядит это так - когда тебе не нужно процессорное время - steal=0 постоянно. А вот когда набегают люди или база решила чё-нить посчитать -steal подскакивает до 50%. При этом, чисто по наблюдениям, отзывчивость всего падает не в два раза, как должно быть по цифрам, а миниум раз в 5.

Посмотрев на это блядство, пришлось городить кучу костылей.
1. Вынес апликацию на отдельный инстанс, что б хотя б апач перестал тупить.
2. Закэшировал всё, что можно
3. Дропнул нахер все индексы в базе, что б CouchDB даже не пытался их перестраивать, зароутив все запросы ко вьюшкам на германский сервер. Подождать секунду ответа из Германии оказалось выгоднее, чем ждать 10-30 секунд ответа с сервера в том же датацентре.

Да, о датацентре. Пинг в пределах ДЦ скакал 1-30мс. У меня, блин, в деревне, по wifi, через стену деревьев и 3 километра воздуха, пинг до гугля и то меньше и стабильнее!

Знатно натрахавшись, /me пошёл искать более совершенный хостинг. ИЧСХ, нашёл! Не без помощи форума searchengines.ru, что удивительно. Там живо накидали адекватных вариантов в Австралии, за адекватные деньги. Простым гуглением в Австралии не находилось ничего нормального.

Самый, что мне приглянулся - Vultr. У них VPS по всему миру, за вменяемые деньги - вменяемые параметры.
Панелька - полный восторг. Кроме обычных ubuntu/centos можно загрузить любой свой ISO и поставить туда хоть чёрта лысого, хоть Gentoo. Что я и сделал. В качестве VNC-клиента у них используется noVNC (html5, сокеты, никакой жавы!). Работает всё - просто изумительно.

За те же деньги, что я должен уже Амазону за неполный месяц, тут дают полный месяц, в два раза больше рамы, проца и диска. Ну и траф в 3 TB позволяет не парить мозг.

Железо работает шикарно. Реальный локальный SSD, а не невнятный NAS за три пизды, полноценный двухядерный проц, 2 гигабайта памяти. И база, и апликация, и redis с резервом на 800 мегабайт прекрасно вошли. База среплицировалась и обсчиталась из Германии за пару часов - Амазон же колбасило сутки где-то.

Короче, я счастлив.

Ссылка, само собой, содержит реф-код, ибо хуле бы я тут так напрягался. Но реф-код хороший, дают 20 баксов по нему, что более чем достаточно для теста на пару месяцев.

(7 комментариев | Оставить комментарий)

Апрель 10, 2016
02:00 pm

[Ссылка]

О качестве
Разговорился со знакомым. Занимается бизнесом в России. Такой, вымирающий вид, но крутится пока.

Речь зашла о качестве продукции. Мол, почему в Чехии выпускают одну марку пива уже 600 лет и до сих пор его пить можно, а в России только новые сорта можно пить, да и те пару месяцев, пока качество не изговняется.

Оппонент мотивировал это тем, что народ не привычный к качеству, им это не надо, они за это платить не будут. Но после нескольких контрпримеров пришли к тому, что в России нельзя делать бизнес с заделом на много лет - если бизнес не успел окупиться в течении 2-3 лет, то с вероятностью 100% его отберут и твои денежки тю-тю безвозвратно. При этом новый владелец будет заниматься только одним - выжиманием соков из предприятия с целью получения максимальной прибыли. Никаким качеством при этом даже пахнуть не будет.

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

В итоге пришли к тому, что проблема не в людях (которые, по моему мнению, везде одинаковые), а во власти, которая не даёт работать бизнесу и, таким образом, не только косвенно, но и прямо влияет на остальные процессы в стране - вплоть с качества пива.

(4 комментария | Оставить комментарий)

Май 4, 2015
09:52 am

[Ссылка]

1000 слов
http://www.imdb.com/title/tt2179136/
https://ru.wikipedia.org/wiki/Кайл,_Крис

Охуенный фильм, конечно, нет слов. Иствуд - молодец, это без вариантов. В начале смотрелось как художка, а на титрах пришлось лезть в гугль.

Вообще, весь фильм преследовала Меганезия.

Во-первых, пошел человек воевать. Ни за что, ни про что. Хотя был критерий - 1000 слов, что я буду делать на гражданке после окончания войны". Ответил бы Крис - жил бы в своей Америке, без вариантов.

Во-вторых, отличный тест. Не понимаешь, что будет дальше - сиди в своём Техассе. Понимаешь - едь и мочи, не парясь пиздастраданиями. Ну, подумаешь, пацан. Он гранату несёт - значит мочить его - закономерный шаг в достижении цели. Совершенно похер, какой длины у него шерсть на яйцах.

Но это Америка, да. Программу в мозг вбили. Зачем - забыли. Иди, сражайся, на жену (фактор удерживания на первом круге ответственности) забивай, за общество умирай.

(1 комментарий | Оставить комментарий)

Февраль 18, 2015
11:06 am

[Ссылка]

Обвели вокруг пальца
Воскресенье, 15-е февраля 2015-го года:
Неизвестная группа хакеров украла более 300 миллионов долларов у более чем сотни банков, чьи названия пока не раскрываются. Об этом сообщает газета The New York Times со ссылкой на полученный заранее отчёт «Лаборатории Касперского», который будет опубликован в понедельник 16 февраля.


Понедельник, 16-е февраля, 2015-го года - тишина

Вторник, 17-е февраля, 2015-го года:

Специалисты из российской компании по производству антивирусного компьютерного обеспечения "Лаборатории Касперского" обнаружили масштабный шпионский вирус, который Агентство национальной безопасности США (NSA) помещало в жесткие диски ведущих производителей техники, передает Reuters со ссылкой на данные компании и источники в NSA.


Детали-то будут? Или так, попиздеть вышли?

(4 комментария | Оставить комментарий)

Январь 5, 2015
08:59 pm

[Ссылка]

Толерантность к нетолерантным
Оригинал взят у zlata_gl в Толерантность к нетолерантным
Толерантность к нетолерантным - это тот камень, который Бог демократия создала и сама не может поднять.

(3 комментария | Оставить комментарий)

Январь 4, 2015
10:03 pm

[Ссылка]

12 хитрых планов Геракла
Исходного автора найти не удалось, так что репостнул к себе.



12 хитрых планов Геракла

1. Геракл назначил Немейскому льву персональную пенсию и гарантировал неприкосновенность его семье. Когда лев издох от старости, произнёс скорбную речь на могиле.

2. Каждой голове Лернейской гидры Геракл отдал в кормление по министерству. Когда на месте одной отожравшейся головы стало вырастать по две, – придумывал для каждой новую хлебную должность.

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

4. В течение 10 лет Керинейская лань пыталась прийти к Гераклу, но он успешно отгораживался от неё таможенными барьерами, вёл с ней молочные и мясные войны, и снял про её отца фильм «крёстный батька». Оскорблённая лань убежала подальше от Геракла, а он вслед обругал её матерными словами.

5. Геракл долго уговаривал Эриманфского вепря не терроризировать округу. Даже перестал покупать у него минеральную воду и хванчкару, одновременно призывая его к мирному диалогу. Когда же свинья настолько обнаглела от безнаказанности, что напала на самого Геракла, то герой загнал её в горы, погрозил ей пальцем и отпустил, опасаясь порицания со стороны Эврисфея. Через какое-то время он опять начал покупать у Вепря боржом и киндзмараули.

6. Чтобы очистить авгиевы конюшни, Геракл нанял таджиков. Но те оказались бессильны, потому что кроме коней туда же гадили все головы Лернейской гидры, а также Стимфалийские птицы и сам Геракл. Причём, гадили обильнее, чем лошади Авгия.

7. Критский бык боднул Геракла в морду так сильно, что ему пришлось вводить в лицо ботокс. Геракл объявил во всеуслышание о своей сокрушительной победе над Быком, а чтобы лучше верили, учредил спортивные игры в Сочи. Некоторые авторы полагают, что бык был не критский, а кипрский.

8. Кобылиц Диомеда, питающихся человеческим мясом, Геракл поселил в центре столицы, и запретил милиции на них охотиться. Кобылицы свободно бродили по улицам и ели людей. Иногда народ восставал против этого, и тогда Геракл сажал зачинщиков за экстремизм.

9. Пояс царицы Ипполиты очень хотел убежать от хозяйки к Гераклу. 15 лет Геракл бесплатно поставлял царице газ, чтобы она держала пояс у себя. В итоге пояс убежал от царицы сам. Геракл очень не хотел его брать, но пояс был так настойчив, что Геракл капитулировал. Правда, корону Ипполиты и ожерелье Ипполиты, которые намылились к нему вслед за поясом, Гераклу с большим трудом, но удалось-таки вернуть обратно царице.

10 и 11. На самом деле Геракл не похищал волшебных быков Гериона. Они ему достались в наследство. Может быть именно поэтому, Геракл так легко начал их резать и продавать на мясо атлантам. Те за это давали ему зёлёные яблоки из сада Гесперид. На каждом зелёном яблоке был нарисован портрет атланта, что очень веселело Геракла. Сколько ещё осталось коров, и что будет, когда они кончатся, он не думал.

12. Пса Цербера Геракл посадил в совет по правам человека, отдал ему для агитации радиостанцию Эхо Аида, несколько телеканалов, политических партий и движений. Когда происходило что-то плохое, Геракл тыкал пальцем в Цербера и говорил «это не я, это всё он». А сам кидал Церберу новую кость.

В награду за эти подвиги Зевс заживо отдал Геракла на растерзание белоленточным гарпиям, либеральным ехиднам и однополым циклопам.

(2 комментария | Оставить комментарий)

Июнь 24, 2014
03:41 pm

[Ссылка]

Сила ipv6
Успев познакомиться с ipv6, трудно от него отказываться. Провайдер дома даёт ipv6 из коробки (ну, почти). Провайдер в офисе - не даёт вообще, хотя намекал, что типа может как-то. Пока он там соображает, что он может, а что нет, плюнул и сделал себе перманентый ipv6 через свой сервер.

Делать думал через какой-нить vpn, в итоге остановился на ssh, благо давно знал, что оно умеет чё-то там с tuntap'ами.

В начале это было три скрипта, в итоге не осталось ни одного.

Итого, конфигурация.

Сервер с ipv6, в качестве точки выхода:

# cat /etc/conf.d/net
...
tuntap_tun222="tun"
config_tun222="2a01:04f8:****:****::dead:bee1/123"
...

Интерфейс tun222 в автозагрузке.

Клиент, мой ноутбук:


# cat /etc/conf.d/net
...
tuntap_tun222="tun"
config_tun222="2a01:04f8:****:****::dead:beef/123"
routes_tun222="default via 2a01:04f8:****:****::dead:bee1 metric 2000"
...

Метрика такая, что б юзать нативный ipv6, где он будет.

Ну и последний штрих:
# cat /etc/supervisor.d/ipv6.conf
[program:ssh_ipv6]
command=/usr/bin/ssh ***.*** -w 222:222 -N
process_name=%(program_name)s
directory=/root
user=root

Пытаюсь заставить работать без рута, но чё-то не хочет, даже если девайсы создаю обычным юзером.

В итоге, у меня есть постоянно красивый адрес ipv6.

Tags: ,

(6 комментариев | Оставить комментарий)

Май 18, 2014
02:28 pm

[Ссылка]

Про новый дизайн ЖЖ
Это какие-то СУПаратисты...

(5 комментариев | Оставить комментарий)

Май 7, 2014
07:55 pm

[Ссылка]

Идеальный шардинг
Disclaimer: людям, не знакомым с понятием СУБД дальше лучше не читать.

Придумал, наверное, идеальный шардинг для баз данных. Правда, реализовать его на уже существующих базах, видимо, невозможно. Но могла бы выйти интересная база данных, если б я был меньшим раздолбаем.

Начнём с введения - CAP-теорема. База данных может быть непротиворечивой, отказоустойчивой и постоянно доступной. Выберите любые два пункта. Понятие 23/364 я стараюсь избегать, поэтому от непротиворечивости я смело отказываюсь.

Далее, для отказоустойчивости и постоянной доступности нам нужен режим master-master. Хорошо - что бы любая (я сказал - любая) нода могла быть мастером. В идеале - что б любая нода была мастером не только для одной шарды, а для любой. Да что там "в идеале", это _минимальное требование_ к отказоустойчивой базе.

Как мы собираемся обеспечивать восстановление после split brain - тема отдельной статьи, я к этому ещё вернусь, думаю. Пока опишу только моё видение идеальной доступности. По записи-чтению.

Шардинг, в классическом представлении - горизонтальное разбиение данных. В качестве признака разбиения выступает какой-то ключ - синтетический (придуманный базой данных для данного куска данных) или реальный (одно из полей записи). В тех же классических примерах рекомендуют выделять, например, чётные индексы на одну ноду, нечётные - на другую. Вопрос добавления третьей ноды в классической литературе стыдливо опускают (страшное слово "решардинг").

Зачастую, данные разделяют по датам. Например, по месяцам. Новый месяц (год, день) - новая шарда. Это допустимо в однонодовых (кластерах с одним мастером) системах, но не в распределённых, где принято равномерно размазывать шарды по кластеру и такое разделение ничего толком не привнесёт.

Примеры из жизни. Riak использует синтетический ключ для шардинга. На практике - хэш от primary key документа. Это позволяет ему предсказуемо равномерно распределять все шарды по нодам. Вопрос решардинга так же опущен - "делается автоматом, невидимо для юзера, с минимальным даунтаймом". Ну да, ну да, так уж и невидимо оно мои терабайты будет по сети пересылать.

В RethinkDB для шардинга используется primary key. Чем плохо - если primary key взят из жизни, т.е. постоянно увеличивается (что дата, что номер строки, всё-равно будут расти). Соответственно, раз в N времени придётся делать решардинг. Про решардинг в RethinkDB ничего не скрывают "их бин капутен, даунтаймен их N часовен", где "N" - от единиц до десятков. Смотря какая база. Мой личный тест - 4-6 часов для базы в 20кк записей (около 10 гигабайт данных). Всё это время, на счастье, в базу можно писать, можно читать, но только по id-шкам. Вторичные индексы во время сего процесса не доступны. Спасибо, родные. Букву "A" из теоремы с вами не сварить.

И, честно, я могу их понять. Они заранее привязались к тому, что шарда - это что-то большое, и, важно, неделимое. А если неделимое становится очень большим, то резко взять и переместить это на другую ноду, что б восстановить доступность и пресловутое "n" (число реплик) становится трудновато.

А ответ лежит на поверхности.

Я долго пытался понять, почему мне так хочется применить сетевые технологии роутинга (BGP) к базам данных и, наконец, понял. Если сделать шардинг и роутинг шард по модели сетевого роутинга - всё становится на места, причём элементарно и просто.

Пример.

Есть кластер из нескольких нод. Кластер хранит, например, 32 шарды (дефолтное магическое число в RethinkDB). Каждая шарда должна анонсировать себя в кластере - так, как это делают AS-ки в интернете. Если шарда номер 12 доступна на сервере A и B, то любой желающий должен иметь возможность её оттуда получить. Для этого всего лишь надо опросить таблицу роутинга (которая распространяется по всему кластеру - абсолютно аналогично BGP) и обратиться к нужной ноде за данными (разумеется, роутинг может быть реализован средствами ноды - что б не переусложнять клиентов, да и с доступом так проще будет - для клиента весь кластер будет доступен с одной ноды - опять-таки, как в интернете).

Что может происходить дальше. Какая-то из нод может умереть. Вручную (админ поставил на профилактику) или случайно (экскаватор, кабель, алкоголь). Что должно произойти - очевидно. Маршрут до шард на этой ноде просто протухнет и к ней перестанут обращаться.
Как только сервер вернётся в строй, маршрут вернётся на место (поднявшаяся нода его распространит по сети) и данные с него станут доступны.

Более того, такая схема позволяет делать управление нагрузкой, опять-таки, по аналогии с роутингом. У одного маршрута метрика 1, у второго - 2, значит вначале пытаемся попасть на первый, если не доступен - на второй. Таким же простым образом можно делать cross-datacenter взаимодействие, банально меняя метрику и маршрутизацию. Есть данные в твоём датацентре - бери их. Нету - бери по более дорогому маршруту (можно заранее предсказать, какие данные будут ближе, когда они будут доступны и т.п.).

Но и это ещё не всё. Можно воспользоваться ещё одной замечательной фенечкой из интернет-роутинга - разделение на подсети.
Т.е. в любой момент слишком большую шарду можно начать разбивать на куски, постепенно копируя их на другие сервера. Т.е. не будет строгого роутинга по номеру шарды, а будет динамическое вычисление нужной ноды, где есть подходящие мне данные.

Пример, на ноде A есть шарда 192.168./16, метрика - 12
А на ноде B есть шарда 192.168.12/24, метрика - 1

Если мне нужны данные из диапазона 192.168.12.2 - 192.168.12.8, то я полезу на ноду B.

А нода B, например, может подсасывать остальные куски шарды, постепенно расширяя свой диапазон покрытия и заявляя об этом сети. Этим может заниматься специальный демон. Обычные цели кластера (копий данных должно быть N) расширятся на простое правило "таблица роутинга должна стремиться становиться меньше".
Переносить шарды станет легко и просто - просто постепенно переписываем данные с ноды на ноду, объявляя их существование сети уже в процессе копирования (а не по завершению процедуры через 100500 часов, как в обычных схемах).

Но и это ещё не всё №2. То, что описано в предыдущем абзаце, можно использовать для защиты от сбоев.
Например, умер последний мастер шарды номер N, а какому-то клиенту жутко захотелось записать туда данные.
В обычной схеме это означает, что данные писать некуда (пока кластер не решится выбрать нового мастера для этой шарды) и читать неоткуда. В схеме же с BGP-роутингом, данные от клиента могут быть записаны на абсолютно любую ноду в сети, которая тут же объявит, что на ней есть данные указанного диапазона (очень маленького диапазона - всего на 1 документ). Если вдруг нужно будет прочитать эти же данные - они будут доступны (запись в таблице роутинга будет описывать очень короткий диапазон). Как правило, критически нужны данные, записанные недавно, а старые данные нужны гораздо меньше, запросто можно подождать.
В случае же появления нормального мастера этой шарды, демон, описанный выше, тут же пойдет и ликвидирует этот маленький диапазон из таблицы роутинга путём переноса этого документа на нужный мастер и склеивания двух записей в таблице роутинга в одну.

Я кончил и закурил. У меня всё.

Теперь осталось дождаться такую базу данных и я буду счастлив. Ну если только она будет не на Java.

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

Tags: , , ,

(11 комментариев | Оставить комментарий)

[<< Previous 10 entries]

Тут никогда небыло, нет и не будет Эльфов Разработано LiveJournal.com