Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1699 сообщений
Cообщения с меткой

облако - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

«Есть плюсы как для админов, так и для разработчиков»: Олег Анастасьев про облако Одноклассников

Среда, 09 Августа 2017 г. 17:03 (ссылка)





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



Поэтому переход Одноклассников от подхода «каждый сервер занимается своей задачей» к облачному подходу «единый пул ресурсов распределяется по необходимости» вызвал у нас вопросы. Мигрировать такой большой проект с 11-летней историей на новую систему непросто — что именно побудило пойти на эти трудозатраты? Чем использование облака в ОК отличается от использования публичных сервисов? Почему проекту не подходят стандартные решения вроде Mesos и Kubernetes, а вместо этого было сделано собственное one-cloud?



На эти и другие вопросы нам ответил ведущий разработчик Одноклассников Олег Анастасьев, уже знакомый читателям Хабра.





— Мы помним, что у вас есть «Правило большого З»: любое техническое действие должно отвечать на вопрос «Зачем?». Так вот, зачем вам понадобилось облако?



— Одна из причин в следующем. Оперирование напрямую с железками — это по большей части прерогатива системных администраторов, или system reliability engineers, называй их как хочешь. Мы хотим двигать разработчиков ближе к продакшену. А чтобы это сделать, надо дать им способ общаться с продакшеном таким способом, чтобы избавить людей от ненужной бюрократии, при этом не дав ничего повалить. И это один из способов решения задачи.



Другая причина — возможность обеспечить более плотную загрузку серверов, повысив утилизацию дата-центров.



— Обычно про облака и плотную загрузку серверов говорят в таком контексте: «если у стартапа сегодня тысяча пользователей, а завтра миллион, с облаком можно быстро отмасштабироваться и использовать необходимое количество ресурсов, не переплачивая за неиспользуемое».



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




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



Во-вторых, хотя Одноклассники в целом существуют давно, в них запускается довольно много различных новых продуктов: те же трансляции появились относительно недавно, много новых продуктов для администраторов групп, частных объявлений, музыки; наконец, мессенджер ТамТам. Про такие продукты заранее сложно оценить, насколько успешными они окажутся, как быстро их понадобится масштабировать. И если каждый сервер занимается своей задачей, неочевидно, сколько серверов требуется выделять. Это та же стартап-проблематика.



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



— С плюсами стало понятнее. А пришлось ли ради них соглашаться на минусы? Скажем, причиной разделения задач между серверами вы ранее называли изоляцию отказов. Не пострадала ли отказоустойчивость от того, что теперь этого разделения нет?



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



— Почему потребность в облачном подходе ощутили именно сейчас? Что-то изменилось вообще в индустрии, или конкретно в Одноклассниках?



— Я думаю, что тут сошлись три фактора. В мире стали возникать новые более-менее опенсорсные системы управления инфраструктурой, и из подобных широко известных компонентов мы в нашей новой системе используем Docker. При планировании расширения инфраструктуры мы поняли, что место в существующих дата-центрах скоро закончится, и нам надо либо строить новый, либо уплотняться в существующих. И у нас освободились ресурсы, чтобы эту задачу наконец решить.



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



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



Понятно, что экономически невозможно просто поставить рядом с нашим дата-центром ещё один такой же большой с облаком, и переводить всё туда, надо использовать уже работающую технику. Поэтому, вводить всё больше и больше инфраструктуры в облако — сложная задача, выполняющаяся постепенно, её нельзя «просто взять и сделать».







А с другой стороны, тут требуется и поддержка со стороны разработчиков, они должны что-то менять в коде, делать контейнеры своих приложений (учтём, что всего у нас более чем 150 различных микросервисов)… В общем, это большой процесс. Первая версия облака у нас была написана и запущена далеко не один месяц назад, но миграция систем в облако всё ещё идёт.



— А насколько легко добиться этой «поддержки со стороны разработчиков» — не приходится ли сталкиваться с «нам тут фичи пилить надо, не хочется отвлекаться на инфраструктурные вопросы, лучше мы в облако попозже перейдём»?



— У меня есть чёткое убеждение, что если люди сами не хотят пользоваться новой системой, если она не даёт им каких-то плюсов по сравнению со старой, то их туда палкой не загонишь. И у нового облака есть плюсы как для админов, так и для разработчиков.



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



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



— Многие крупные компании по всему миру делают свои облака. А почему они не готовы просто пользоваться условным Amazon AWS — потому что своё получается дешевле, потому что переживают о безопасности, или потому что хотят большой уровень контроля и доступа?



— Есть и те, кто идут в Amazon — так делают Netflix, пионеры облачных вычислений. Но они там поверх AWS запускают свою собственную систему автоматического управления инфраструктурой, они уже дошли до того, что им удобнее иметь свою надстройку над AWS.



Но в любом случае это зависит от того, что у компании было изначально и каковы текущие обстоятельства. Есть ли у компании свои железные сервера? Есть ли специалисты, которые умеют развивать инфраструктуру? Все компании выбирают свой путь, очень многое зависит от доступности специалистов, от того, с чего они начинали, и даже от географического положения. Для крупной российской компании, ориентированной на российский рынок, хоститься на Amazon будет просто глупо, потому что он там, а мы здесь.



— А для тех сотрудников Одноклассников, которые будут пользоваться вашим облаком, чем это будет отличаться от использования того же AWS?



— Amazon — немного другая система. Она более старая: хотя они пытаются идти в ногу со временем, делать вещи вроде AWS Lambda, использовать современный софт, там много легаси. И у нас это по-другому выглядит, потому что нет этого легаси.



Кроме того, AWS — универсальный продукт, который подходит для хостинга самых разных вещей. Как и любой универсальный продукт, он не очень удобен в контексте конкретной задачи, там много всяких штук, которые нам не нужны и только путают.



А поскольку мы делаем конкретный продукт для нас, нам работать с ним проще, управление понятнее, и его можно естественным образом положить на то, как у нас принято делать какие-то штуки. И так не только с хостингом, но и с другими составляющими облака, где тоже уходили от универсальных решений к собственным — например, one-cloud.



— Конкретно про one-cloud вы осенью собираетесь рассказывать подробно на наших конференциях Joker и DevOops, а пока тогда расскажите кратко: что это вообще?



— Это операционная система уровня дата-центра — то есть большая распределённая система, позволяющая автоматически управлять инфраструктурой с помощью описаний задач («задача» — широкое понятие, она может включать тысячи реплик, распределённых на сервера в нескольких ДЦ). Кроме того, она может автоматически поддерживать работоспособность задачи при различных сбоях. Допустим, в простейшем случае, если сервер вылетает, то система автоматически восстанавливает необходимое количество реплик на других машинах.



— И использовать популярные опенсорсные решения вроде Kubernetes не стали использовать тоже из-за их универсальности?



— Да. Мы рассматривали и Kubernetes, и Mesos. Было ясно, что и первый, и второй в своём обычном виде не ложатся на то, что мы хотим. Мы могли бы дотянуть и тот, и другой до того, что нам необходимо. Но мы оценили работу, которую нужно было бы проделать, и работу на то, чтобы написать своё, и оказалось, что объём работы приблизительно одинаковый. В итоге решили написать своё, которое получится более удобным и понятным, более надёжным, более заточенным под нас, под наши требования и инфраструктуру.



— Поскольку про one-cloud будете рассказывать и на Java-конференции, и на DevOps-конференции, хочется узнать: эти доклады будут различаться?



— Да. На DevOops доклад будет в большей степени про процессы: как построить DevOps-процессы, когда у вас есть облака или своя система управления дата-центром, и как при этом не потерять отказоустойчивость. И об обеспечении изоляции задач на одной машине. Поскольку для такой большой распределённой системы очень важна отказоустойчивость, большая часть доклада будет именно о том, как она обеспечивается.



На Joker планируется сделать меньше про процессы обеспечения отказоустойчивости, а больше про то, как облако устроено внутри, что отказоустойчивость с этой стороны обеспечивает. Кроме того, есть идея рассказать больше об эксплуатации Java-приложений в контейнерах. Потому что наше облако — наверное, единственное, у которого сто процентов запускаемых задач написаны на языке Java, и есть опыт, полезный тем, кто на Java пишет.



— В случае с Joker ваш предварительный план доклада состоит из пунктов «содом», «гоморра» и «кишки». Там ожидать хардкора?



— Честно говоря, мне сложно судить, потому что у меня как у одного из авторов one-cloud искажённое восприятие. Мне вообще кажется, что всё очень просто, но другие люди не всегда оказываются с этим согласны. Мне самому интересно, что получится в итоге.







Обе упомянутых конференции, DevOops и Joker, состоятся осенью в Санкт-Петербурге: DevOops 20 октября, а Joker — 3-4 ноября. На сайтах обеих можно увидеть, что ещё там будет, помимо доклада Олега — и на сайтах обеих уже можно приобрести билеты.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/335234/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_novate

Гаджеты: Левитирующий светильник-облако, который сделает любую комнату неповторимой

Вторник, 08 Августа 2017 г. 21:06 (ссылка)




Не знаете, как сделать свой дом лучше, светлее, а может быть хочется и вовсе изменить всю атмосферу? Возможно, следует подумать о приобретении подходящего светильника. Один, весьма интересный по конструкции и функционалу, был создан совсем недавно американским дизайнером.

Подробнее..

http://www.novate.ru/blogs/080817/42516/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Леонид_Кравчишин

Для тебя- букет белых роз...

Суббота, 05 Августа 2017 г. 14:56 (ссылка)
vip-otkrytki.ru/dlya-tebya-...?_utl_t=li

Для тебя- букет белых роз | Музыкальные Открытки Бесплатно

Для тебя- букет белых роз... > http://vip-otkrytki.ru/dlya-tebya-buket-belyx-roz/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как мы добавили RAM в серверы HPE

Пятница, 21 Июля 2017 г. 10:04 (ссылка)





Качество и надежность DRAM сейчас важнее, чем когда-либо, в основном из-за растущего использования виртуализации серверов. Конечно, стоит отметить что модули RAM, по мнению многих IT-специалистов, являются одним из самых надёжных элементов сервера и выходят из строя последними. Виртуализация имеет много преимуществ, но она значительно увеличивает количество необходимой памяти в сервере для обеспечения оптимальной производительности максимального числа виртуальных машин. По данным HP за 5 лет с 2007 до 2011 средняя память, установленная на всех серверах HP ProLiant, выросла более чем на 500% — от 4 ГБ до более чем 30 ГБ на сервер.



В настоящее время как облачный провайдер мы используем blade-серверы HP ProLiant BL460c Gen8 на шасси HPE BLADESYSTEM C7000 ENCLOSURE. Полностью QuickSpecs тут, обозначим лишь спецификацию RAM.



Standard (Preconfigured Models)

64GB (8 x 8GB) DDR3 1600MHz RDIMMs at 1.5V

64GB (4 x 16GB) DDR3 1866MHz RDIMMs at 1.5V

32GB (4 x 8GB) DDR3 1600MHz RDIMMs at 1.5V

32GB (2 x 16GB) DDR3 1866MHz RDIMMs at 1.5V

32GB (4 x 8GB) DDR3 1333MHz RDIMMs at 1.35V

32GB (2 x 16GB) DDR3 1600MHz RDIMMs at 1.35V

16GB (2 x 8GB) DDR3 1866MHz RDIMMs at 1.5V

16GB (4 x 4GB) DDR3 1333MHz RDIMMs at 1.35V

16GB (2 x 8GB) DDR3 1600MHz RDIMMs at 1.35V



Maximum

(LRDIMM) 512GB (16 x 32GB) up to 1333MHz at 1.35V

(RDIMM) 256GB (16 x 16GB) up to 1866MHz at 1.5V

(RDIMM) 384GB (16 x 24GB) up to 1333MHz at 1.35V

(UDIMM) 128GB (16 x 8GB) up to 1600MHz at 1.5v



Если требуется помощь, чтобы разобраться в обозначениях типов памяти и их различиях, рекомендуем полезную статью на Хабре.



Отметим, что в случае с использованием в оборудовании для облака, то есть в системах, требующих масштабируемости и отказоустойчивости в ущерб дешевизне, используется регистровая память c функцией коррекции ошибок (ECC RDIMM).



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



В поисках лаконичного ответа был найден White paper от HP, точнее даже два, один 2011 года, а второй 2017. Что мы выделили для себя:




  • HP не является производителем модулей RAM.

  • Когда вы видите бренд HP Qualified Memory, это означает, что DRAM прошла серьёзную проверку качества и тестирование с используем проприетарных диагностических инструментов и специализированных диагностических тестов, чтобы обеспечить высокий уровень производительности и доступности серверов HP ProLiant.








  • До того, как модуль DRAM получит бренд HP Qualified Memory (наклейку), он проходит интенсивный четырехфазный процесс проверки качества. HP задолго до разработки продукта сообщает производителям модулей памяти (Tier 1 memory suppliers) требования к DRAM. Группа HP Memory Core получает модули DIMM непосредственно от поставщика-производителя. На диаграмме процесса HPMQ (HP Memory Qualification) даны краткие описания четырех фаз процесса проверки качества. На наш взгляд, важно обратить внимание на то, что не описано какая доля полученных на проверку модулей отсеивается.





    В результате HPMQ не меняется расположение микросхем, кажется, дизайнер ошибся




  • Память проверяется так, чтобы она не становилась слишком горячей и по этой причине не забыла ваши данные.

    HP-validated memory is tested so that it does not get too hot and forget your data. HP-validated memory is tested so that it does not cause the system to shut-down due to power overload.

  • HP Qualified Memory обладает такой же полной гарантией, что и серверы ProLiant.

  • Если будет установлено, что отказ сервера вызван RAM под другим брендом (не-hp) или в любое время будет обнаружено, что сторонняя часть наносит ущерб компонентам или системам HP, стоимость ремонта, включая поврежденные детали HP, оплату труда и проезда, не будет покрываться по стандартной гарантии HP. Но установка сторонней памяти не снимает сервера ProLiant с гарантии HP. Подобное заблуждение часто приводится пользователями IT-форумов как аргумент «за OEM» в ходе обсуждения подбора памяти для сервера.




Сколько стоит HPMQ и сервис HP для покупателя? Для наглядности и понимания об уровне цен приложены скриншоты с Яндекс.Маркета. Мы не предлагаем расценивать это как полноценное исследование рынка, особенно по причине минимальных цен на HP RAM от неизвестных нам продавцов, которые на 60% ниже средней рыночной.











Почему для сравнения мы выбрали оперативную память от Kingston?




  • Каждый серверный модуль Kingston для конкретной системы должен пройти испытания на принудительный отказ. Эта уникальная процедура позволяет отбраковывать потенциально дефектные модули, не допуская их попадания в отгружаемые партии продукции. В том числе, присутствует проверка надёжности при разогреве. Полный список проверок качества здесь.

  • Являясь долговременным членом Совета директоров JEDEC, Kingston Technology способствует созданию отраслевых стандартов для технологий изготовления памяти. Все модули памяти, выпускаемые компанией Kingston, отвечают требованиям JEDEC и основным техническим условиям, применяемым ведущими изготовителями полупроводниковых устройств.

  • Техническая поддержка и тест-драйв. Есть официальное представительство в РФ (в отличии от Crucial, например), по запросу всегда есть необходимое количество плашек для отгрузки. Серверную память можно взять на тест-драйв и посмотреть, как она будет работать в реальных условиях на конкретном сервере.

  • «Пожизненная» гарантия. Если модуль памяти откажет, его заменят по гарантии.



У Kingston есть большое количество различных вариантов модулей RAM. Подходящий можно подобрать на их сайте. Потенциальные проблемы с несовместимостью должны отсутствовать, так как по заявлениям Kingston, модули были протестированы на всех соответствующих вариантах серверов. В нашем случае, мы выбирали для HP BL460C G8, проблем в работе не возникло.



Что дала нам покупка модулей памяти Kingston? При значительном объёме закупки удалось серьёзно сократить бюджет на модернизацию. Нам не удалось выявить значимых отличий в проверке качества RAM от Kingston и HP. Не найдя оснований для того, чтобы оплатить почти в два раза больший счёт, мы выбрали модули Kingston. Это также позволило не перекладывать дополнительные издержки на потребителей наших услуг.



В этой статье мы не пытаемся обратить внимание на дороговизну комплектующих от HP. Более того, мы довольны использованием серверов HP ProLiant и HP BladeSystem. Для поддержки большого количества виртуальных машин на одном физическом сервере требуется больше памяти, больше подключений для хранилищ данных и больше сетевых подключений, поэтому, по нашему мнению, серверы HP, сертифицированные для VMware, являются одними из лучших платформ для виртуализации, так как они были построены «with virtualization in mind».



Сертификация VMware даёт нам возможность стабильного использования всеми опциями платформы виртуализации VMware, которые значительно повышают эффективность и надёжность работы всего облака:




  • VMware VMotion;

  • VMware DRS;

  • VMware HA;

  • и прочие.



Выбранное оборудование для облачного провайдера является основой для построения всей бизнес-системы, которая в конечном счёте должна обеспечить клиентов услугами с высоким уровнем доступности и качества (SLA от 99,95%) по конкурентной цене. Это является причиной поиска оптимальных решений.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/333786/

Комментарии (0)КомментироватьВ цитатник или сообщество
Kantemirova_Irina

Бесплатное «облако» на 100Гб для резервных копий

Суббота, 08 Июля 2017 г. 19:23 (ссылка)

Бесплатное «облако» на 100Гб для резервных копий


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


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


Рекомендую присмотреться к простому и бесплатному «облаку» Degoo — в нём Вам «с порога» дают навсегда целых 100 Гб для хранения резервных копий с возможностью расширения этого пространства до 500 Гб.


Читать далее
Kantemiirina
Метки:   Комментарии (8)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Семинар «Облака и реальность: кейсы, грабли, хорошие новости», 13 июля, Санкт-Петербург

Пятница, 07 Июля 2017 г. 13:16 (ссылка)





Привет, Хабр! Мы готовим к запуску новый курс Университетов DataLine. На этот раз про наши знания в делах облачных. Первый семинар пройдет в Санкт-Петербурге 13 июля – для нас это двойная премьера :-)



На вводном семинаре курса расскажем про практику IaaS в России и в мире, поделимся лайфхаками в области миграции и поговорим об облаке будущего.



У нас осталось всего несколько мест, и мы будем рады видеть ИТ-директоров, инженеров и всех тех, кто занимается обслуживанием ИТ-инфраструктуры.



О чем поговорим:




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

  • Миграция в облако: типичные ошибки и лайфхаки.

  • Облако завтрашнего дня: наш взгляд на ключевые тренды в развитии технологий и сервиса в целом.



После семинара для всех участников вкусный фуршет.



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

Если вы в Петербурге, заходите в гости!
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332612/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Kubernetes & production — быть или не быть?

Пятница, 07 Июля 2017 г. 09:01 (ссылка)

Сотни контейнеров. Миллионы внешних запросов. Миллиарды внутренних транзакций. Мониторинг и нотификации проблем. Простое масштабирование. 99% up time. Деплои и откатывание релизов.







Kubernetes как решение всех проблем! «Быть или не быть?» — вот в чем вопрос!





Disclaimer



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



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



Я попытаюсь описать весь опыт, полученный нами в `Lazada Express Logistics`, компании являющейся частью `Lazada Group`, которая в свою очередь — часть `Alibaba Group`. Мы разрабатываем и осуществляем поддержку систем автоматизирующих по-максимуму весь операционный цикл доставки и фулфилмента в 6 крупнейших странах Юго-восточной Азии.



Предпосылки к использованию



Однажды представитель компании, продающей облачные решения по всему миру, спросил у меня: «А что для Вас 'облако'?». Помешкав пару секунд (и подумав:«Хммм… наш диалог явно не о взвешенных в атмосфере конденсациях водяного пара...»), я ответил, что, мол, это как будто один сверх-надежный компьютер с неограниченными ресурсами и практически не имеющий накладных расходов на передачу потоков данных(cеть, диск, память, т.д.). Словно это мой лэптоп работающий для всего мира и способный держать такую нагрузку, а я в одиночку способен им управлять.







Собственно зачем нам это облачное чудо? Все в общем-то очень просто! Мы стремимся облегчить жизнь разработчиков, системных администраторов, devops-ов, тех-менеджеров. А такая вещь, как правильно приготовленное облако, многократно облегчает жизнь всем. Да и помимо всего прочего, мономорфные системы работающие на бизнес всегда дешевле и порождают меньше рисков.



Мы задались целью найти простую, удобную и надежную платформу приватного облака для всех наших приложений и для всех типов ролей в команде перечисленных выше. Провели небольшое исследование: Docker, Puppet, Swarm, Mesos, Openshift + Kubernetes, Kubernetes — Openshift… остановились на последнем — Kubernetes безо всяких аддонов.



Функционал описанный на самой первой странице отлично вписывался и годился для всего нашего предприятия. Подробное изучение документации, болтовня с коллегами и небольшой опыт быстрой пробы. Все это дало уверенность, что авторы продукта не врут, и мы сможем получить наше великолепное облако!



Засучили рукава. И понеслось…



Проблемы и их решения









3-х уровневая архитектура



Все идет с основ. Для того чтобы создать систему, способную хорошо жить в кластере Kubernetes, вам придется продумать архитектуру и процессы разработки, настроить кучу механизмов и средств доставки, научиться мириться с ограничениями/концепциями мира Docker и изолированных процессов.







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



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


  • Hardware — сервера, физические сети

  • Cluster — в нашем случае Kubernetes и системные сервисы поддерживающие его (flannel, etcd, confd, docker)

  • Service — непосредственно процесс упакованный в Docker — микро/макро сервис в своем домене



Вообще идея 3-х слойной архитектуры и задач связанных с ней — это тема отдельной статьи. Но в свет она выйдет не раньше, чем этот самый чек-лист будет безукоризненно полон. Это может и не случиться никогда :)




Квалифицированные специалисты



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







Причина тому — новые технологии, которые, поступая на рынок, не успевают обрастать нужным объемом документации, обучающих статей и ответов на `Stack Overflow`. Однако, не смотря на это, такие технологии, как в нашем случае, Kubernetes — становятся очень популярными и создают дефицит кадров.



Решение простое — нужно взращивать специалистов внутри компании! Благо, в нашем случае, мы уже знали что такое Docker и как его готовить — остальное пришлось нагонять.



Continuous Delivery/Integration



Не смотря на всю прелесть технологии «умного облачного кластера», нам были необходимы средства общения и установки объектов внутрь Kubernetes. Пройдя дорогу от самописного bash скрипта и сотен ветвей логики, мы закончили вполне понятными и читаемыми рецептами для Ansible. Для полноценного превращения Docker файлов в живые объекты нам понадобилось:




  • Набор стандартных решений:


    • Team City — для автоматизированных деплоев

    • Ansible — для сборки шаблонов и доставки/установки объектов

    • Docker Registry — для хранения и доставки Docker образов


  • images-builder — скрипт для рекурсивного поиска Docker файлов в репозитории и отправки образов на их основе после сборки в централизованное registry

  • Ansible Kubernetes Module — модуль для установки объектов с различными стратегиями в зависимости от объекта (создать или обновить/создать или заменить/создать или пропустить)









По мимо всего прочего мы изучали вопрос о Kubernetes Helm. Но тем не менее, не смогли найти той самой killer-feature, которая могла бы заставить нас отказаться или заменить Ansible шаблонизацию на Helm чарты. Других полезных способностей этого решения мы не смогли найти.



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



Эти и многие другие вопросы обязывают относиться к Helm как к простому шаблонизатору. Но зачем это?.. если Jinja2, входящая в состав Ansible, даст фору любому не профильному решению.





Сервисы хранящие состояние



Как полноценное решение для любого типа сервисов, включая statefull(имеющие состояние), Kubernetes поставляется с набором драйверов для работы с сетевыми блочными устройствами. В случае с AWS, единственный приемлемый вариант — EBS.



Как вы можете убедится, треккер k8s пестрит кучей багов связанных с EBS, и решаются они довольно медленно. На сегодня, мы не страдаем от каких-то серьезных проблем, помимо того, что, иногда, для создания объекта с персистентным хранилищем требуется до 20 минут. Интеграция EBS-k8s очень, очень, очень сомнительного качества.







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







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



Небольшой пример.

Собирать логи внутри запущенного Docker контейнера нельзя. НО очень много систем и фреймворков не готовы к стримингу в `STDOUT`. Нужно заниматься `патчингом` и осознанной разработкой на системном уровне: писать в пайпы, заботиться о процессах и т.д. Немного времени и у нас есть Monolog Handler для `php`, который способен выдавать логи так, как их поймет Docker/k8s




API Gateway



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



Все довольно просто — нужна единая точка отказа доступа ко всем вашим сервисам.







Есть ряд задач которые мы решали в разрезе Kubernetes кластера:




  • Контроль доступа и лимитация запросов извне — как пример небольшой LUA скрипт проливает свет на проблему

  • Единая точка аутентификации/авторизации пользователей для любых сервисов

  • Отсутствие множества сервисов требующих доступ по HTTP из `мира` — резервирование портов на серверах для каждого желающего сервиса управляется тяжелее, чем роутинг в Nginx

  • Интеграция Kubernetes-AWS для работы с AWS Load Balancer

  • Единая точка мониторинга HTTP статусов — удобно даже для внутреннего общения сервисов

  • Динамическая маршрутизация запросов на сервисы или версии сервисов, A/B тесты (альтернативно проблема может решаться разными pod-ами за сервисом Kubernetes)



Искушенный пользователь Kubernetes поспешит спросить о Kubernetes Ingress Resource, который предназначен именно для решения подобных задач. Все верно! Но мы требовали немного больше `фич`, как вы могли заметить, для нашего API Gateway чем есть в Ingress. Тем более, это всего лишь обертка для Nginx, с которым мы и так умеем работать.




Текущее состояние



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







Что же из себя представляет платформа в текущем состоянии — немного сухих фактов:


  • Всего 2-3 человека для поддержки всей платформы

  • Один репозиторий хранящий всю информацию обо всей инфраструктуре

  • От 10-50 независимых автоматизированных релизов в день — CI/CD mode

  • Ansible как средство управления кластером

  • Считанные часы для создания идентичного `life` окружения — локально на minikube или на реальных серверах

  • AWS-based архитектура на базе EC2 + EBS, CentOS, Flannel

  • 500~1000 pod-ов в системе

  • Лист технологий завернутых в Docker/K8s: Go, PHP, JAVA/Spring FW/Apache Camel, Postgres/Pgpool/Repmgr, RabbitMQ, Redis, Elastic Search/Kibana, FluentD, Prometheus, etc

  • Инфраструктура вне кластера отсутствует, за исключением мониторинга на уровне `Hardware`

  • Централизованное хранилище логов на базе Elastic Search внутри Kubernetes кластера

  • Единая точка сбора метрик и алертинга проблем на базе Prometheus



Список отражает множество фактов, но опущенными остаются явные преимущества и приятные особенности Kubernetes как системы управления Docker процессами. Подробнее с этими вещами можно ознакомится на оффициальном сайте Kubernetes, в статьях на том же Хабре или Medium.


Длинный список наших пожеланий, которые находятся на стадии прототипов или пока еще покрывают небольшую часть системы, тоже очень большой:


  • Система профилирования и трэйсинга — например, zipkin

  • Anomaly detectionмашинно обучаемые алгоритмы для анализа проблем по сотням метрик, когда мы не можем или не хотим понимать что значит каждая метрика/набор метрик в отдельности, но хотим знать о проблеме связанной с этими метриками

  • Автоматическое планирование мощностей и масштабирование как количества pod-ов в сервисе так и серверов в кластере на основе определенных метрик

  • Интеллектуальная система управления бэкапами — для любых stateful сервисов, в первую очередь баз данных

  • Система мониторинга сетей и визуализации связей — внутри кластера, между сервисами и pod-ами, прежде всего (интересный пример)

  • Federation mode — распределенный и связнный режим работы нескольких кластеров





Тaк быть или не быть?



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



Решать вам! Но мое мнение по поводу всего этого: «БЫТЬ!.. но очень аккуратно»
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332108/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Бэкап скриптами в облако Google Cloud Platform (GCP) за пять минут

Среда, 05 Июля 2017 г. 17:05 (ссылка)

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



Резервное копирование в облако — тема уже давно не новая. Каждый выбирает своего облачного провайдера, свои инструменты для копирования и пр. Вендоров много, здесь мы рассмотрим именно Google Cloud Platform. Мой выбор обусловлен стоимостью хранилища и простотой подключения. Мы все реализуем самыми простыми скриптами, без покупки софта, покупки дисковых хранилищ и прочего.



Что мы имеем



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



Выбор облака



Кто-то посоветовал заказчику OneDrive или Google Drive. Этот вариант отпал сразу, ибо это бред, хранить около 10Тб бэкапов на облачном диске. Смотрели в сторону Azure — странное ценообразование и предоплата. AWS или Google Cloud… доверились более известному в массах :) Была еще пара облачных провайдеров, один даже выигрывал немного в цене, но последним аргументом стала оплата без банковской карты.



Два вида копирования



Да, нам нужно было применить две схемы резервирования различных данных:


  1. Репликация существующего набора копий на сервере

  2. Хранение копий длительное время только в облаке

Начнем с матчасти



Подготовка облака



Создаем триал на 300 долларов в Google Cloud Platform (Кому мало — стучите, обсудим).



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



Подготовка машины



С сервером все просто. Идем в раздел документации Google Cloud, открываем раздел Cloud SDK и действуем по инструкциям. В моем случае была машина с Windows Server, потому скачиваем, ставим. Достаточно стандартных параметров при установке, потому далее-далее-готово.

Открываем командную строку, пишем
gcloud init
нам будет предложено авторизоваться в окне браузера. Вводим логин-пароль от Google Cloud. Далее будет предложено выбрать в окне командной строки проект, выбираем созданный ранее. При вопросе включить ли API — Да, Хотим ли управлять Compute Engine — нет.



Репликация хранилища



В двух словах, зачем она нам была нужна. Есть машина на которой имеется набор резервных копий в определенном каталоге (c:\bak\). Это зашифрованные архивы и их нужно хранить где-то снаружи. Без проблем. Открываем командную строку, пишем
gsutil -m rsync -r -d -e -C file://c:\bak gs://bakwin

  • c:\bak — каталог с копиями для репликации в облако

  • bakwin — "Сегмент" в облачном хранилище Google Cloud Storage, который мы создали ранее



Тут стоит оговориться, что я экспериментирую с машиной Windows, но точно так-же это работает и на Linux, только путь к каталогу поправить нужно.



Команда выполнена, все улетело в облако. Сохраняем как скрипт, включаем в планировщик. Все! Реально пять минут.



Резервное копирование каталога



В этом случае нам потребовалось хранить данные за каждый день в отдельном каталоге в Google Cloud Storage. Тоже оказалось все просто, берем бутерброд и наливаем кофе.



Для любителей PowerShell, я делал именно на нем т.к. машина на Windows Server. Модули у нас установились в системе вместе с Cloud SDK. Потому для начала, кроме
Import-Module GoogleCloud
нам ничего не потребуется.



Показываем где у нас каталог для копирования и в какой сегмент его помещать:
$folder = "C:\Bak"
$bucket = "gs:\backupwin"


Тут можно дописать создание каталога по текущей дате копирования:

$date = Get-date -format dd.MM.yyyy
$bucket = $bucket + "\" + $date
mkdir $bucket


Собственно сам скрипт для копирования:

cd $folder
$files = Get-ChildItem -Recurse -Attributes !Directory
$data = @()
foreach ($file in $files) {
$objectPath = $file | Resolve-Path -Relative
$data += @{file = $file; objectPath = $objectPath} #
}
cd $bucket
foreach($element in $data) {
Write-Host $element.objectPath
New-Item -ItemType File -Path $element.objectPath
}


Проверяем, работает. Составляем в скрипт, ставим в планировщик. Вот и вся любовь.



По стоимости хранения 10 Тб данных (в облачном хранилище) оплата будет от 70 долларов в месяц. В целом все работает. Тюнинг скриптов под конкретные условия не применялся.



Вообще резервное копирование в Google Cloud Storage можно использовать и вместе с таким ПО как Cloudberry, Veritas и др. и использовать облачное хранилище как дополнительное пространство для копий. В случае с железом, большинство вендоров уже на уровне хранилищ поддерживают их резервирование в Google Cloud.



Вывод: дешево, быстро, надежно, а перевод из пробной версии в коммерческую происходит без каких-либо перенастроек и банковских карт.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/332474/

Комментарии (0)КомментироватьВ цитатник или сообщество
stertenorva

Google анонсировал революционные функции для облака

Воскресенье, 25 Июня 2017 г. 14:42 (ссылка)

Пользователи Google в скором времени смогут сохранять в облаке не только отдельные файлы, но и всю необходимую информацию. Дело в том, что в корпорации анонсировали новую разработку Backup and Sync, которая значительно расширит «облачные» функции.

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Ограничивать ли пользователей по ресурсам?

Суббота, 24 Июня 2017 г. 19:01 (ссылка)

Сколько я занимаюсь ИТ — столько я слышу от админов «больно жирно будет пользователям, обрежем им трафик / объем почтового ящика / файловую шару / заблокируем сайт / подставить по вкусу». И ровно столько же у меня возникает вопрос: какое ваше дело?

Давайте забудем, что мы ИТ-шники и управляем клёвыми СХД, фермами серверов, почтовыми серверами и посмотрим на всю это катавасию отстраненно. Рассмотрим коммерческую структуру.



1. Чем занимается ваша компания?



Забудьте про производство туалетной бумаги, штанов или даже авиадвигателей.

Правильный ответ: она производит деньги. Причем так, чтобы произведенных денег получалось больше, чем потраченных.



image







2. Кто производит деньги?



А их производят те самые «тупые юзвери», которые просят нажать any key великого и могучего техномага. Даром что техномаг настолько велик, что не может читать инструкции на английском (рабочем языке ИТ), а для русского он и так слишком велик.



image



3. При помощи чего они производят деньги?



Деньги производятся в том числе при помощи ИТ сервисов, включая почтовые серверы для коммуникации с клиентами, интернета, систем учета, бухгалтерии и т.д. В процессе производства денег ИТ сервисы потребляют ИТ ресурсы — сырые мощности (процессоры / ОЗУ / СХД), лицензии, каналы.



4. Кому принадлежит ИТ инфраструктура и ресурсы?



Вот здесь раз от раза я натыкаюсь на то, что администраторы начинают считать серверы, СХД и коммутаторы «своими». Даже немного, и начинают относиться к ним соответственным образом.



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



5. И теперь — кто должен решать, сколько ресурсов может потребить сотрудник бизнес подразделения?



Как мне кажется, это абсолютно точно не должен быть ИТ админ. Просто потому что он понятия не имеет о том, как эти ресурсы приносят деньги.

Потребление ресурсов должно быть неограниченным со стороны ИТ, с практически нулевым весом ИТ в принятии решения о выделении ресурсов на ИТ инфраструктуре. Кроме разве что моментов, когда внезапный рост потребления может положить всю инфраструктуру целиком.



Необходима система внутреннего биллинга, которая вместо ограничения потребления попросту присылает в конце месяца счет начальнику отдела и фин. директору о том, кто сколько и каких ресурсов потребил. В рублях. Просто потому что именно эти два человека понимают какую долю прибыли генерирует данный сотрудник и сколько ему надо ресурсов для генерации этой прибыли.



Вы конечно можете возразить сразу по нескольким пунктам. Давайте их рассмотрим.



image



1. Если не ограничивать соц. сети, то вместо работы все будут только во вконтактике сидеть.



Может быть. Но разве это ваша сфера ответственности и знаний? У сотрудника есть начальник, который оценивает качество его работы. Может быть, конечно, именно начальник попросит обрезать Ивану Ивановичу Иванову доступ к соц. сетям — но это его сфера принятия решения. Может быть это будет политика ИБ, но опять же, это не решение админа.



2. Они безмозглые и ничего не понимают в ИТ. И совсем не думают, что их смешные картинки и видюшки в почтовых вложениях полностью съедят СХД под почту.



Ну на то и есть вы, мозглые и понимающие. Только вот есть снова интересный момент, ничего не воспитывает человека так быстро и эффективно, как воздействие на его кошелек. Один раз остаться всем отделу маркетинга без премии потому что они 90% потребленного пространства в почте потратили на картинки — и их компьютерная грамотность / здравый смысл резко повысятся. А самое главное, стимулировать их повышение будет родными и понятными методами начальник отдела, оставшийся без премии. Вся их премия уйдет на расширение СХД.



image



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



Позвольте, но это классический пример «административная проблема техническими средствами не решается». Проблема с планированием бюджета / экономическим обоснованием закупок в классической модели — это административная проблема на уровне директората, а не админа. Более того, при помощи биллинга вопрос обоснования бюджетов решается сильно проще.

Есть и другая сторона ограничения ресурсов. Вы перестаете контролировать что происходит в компании. Пользователи начинают удалять важную на самом деле почту, потому что новую не могут получить. Важные документы оказываются в облаках, переписка перемещается с корпоративной почты в Яндекс и Мейл.ру. Иными словами, именно слепой репрессивный метод является создателем «теневого ИТ».



image

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/331558/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Как принять закон или обработка данных в распределённых системах понятным языком

Четверг, 08 Июня 2017 г. 10:08 (ссылка)

https://habrahabr.ru/post/330462/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<облако - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda