Облачных вычислений (cloud computing) сегодня очень популярна в России и в мире. Мы не будем здесь подробно описывать суть cloud computing и подход компании Oracle к построению облаков. С ним можно ознакомиться здесь [1]. Общеизвестны такие преимущества облачных вычислений, как построение гибкой, ле

Еще одна порция мифов о частном облаке М Ривкин, Oracle CIS Я собирался назвать эту статью "Мифы о частном облаке", но набрав в Google слова "мифы облако" неожиданно получил множество ссылок на тексты с аналогичным названием. Поэтому название пришлось изменить. Оказалось, что хотя про облачные вычисления много говорят и пишут, у заказчиков наблюдается полное смешение понятий и неверное понимание того, что такое облачные вычисления. В результате эта тема обросла множеством заблуждений и мифов, причем у каждого есть свой набор мифов. Тема облачных вычислений (cloud computing) сегодня очень популярна в России и в мире. Мы не будем здесь подробно описывать суть cloud computing и подход компании Oracle к построению облаков. С ним можно ознакомиться здесь [1]. Общеизвестны такие преимущества облачных вычислений, как построение гибкой, легко перестраиваемой IT инфраструктуры; быстрое развертывание новых сервисов; снижение расходов на IT инфраструктуру; более эффективное использование оборудования; повышение надежности; учет использования вычислительных ресурсов; стандартизация; консолидация; быстрое клонирование баз данных и сред для тестирования и разработки и т д и т п. Многие заказчики понимают преимущества облачных вычислений и уже обсуждают или даже планируют перенос своих приложений в облако и модернизацию своей IT инфраструктуры в облачную. Но при общении с многими заказчиками мы неожиданно обнаружили, что многие неправильно понимают суть облачной инфраструктуры и это непонимание порождает мифы. Например, часто приходится слышать утверждения: “Я не собираюсь переносить свои приложения в облако, поскольку это небезопасно, требует больших инвестиций и переписывания приложений “. Правда это или нет? Как ни странно – и да и нет. Например, безопасность. Да, перенос приложений в ПУБЛИЧНОЕ облако может создать проблемы с обеспечением безопасности, т к инфраструктура публичного облака расположена за рубежом, уровень ее защиты не ясен, контролировать безопасность данных и приложений мы не можем и т д. Но если мы говорим о ЧАСТНОМ облаке, расположенном в Вашем центре обработки данных (ЦОД), то там можно применить все уровни защиты, используемые в традиционной IT инфраструктуре. Это Ваш ЦОД и, например, для СУБД мы можем использовать весь арсенал обеспечения безопасности (шифрование, аудит, разграничение доступа, различные способы аутентификации, защиту от администратора, установление уровня конфиденциальности для отдельных строк, динамически изменяющиеся политики безопасности, firewall и т д. Т. е. тезис о безопасности справедлив для публичного облака и не подходит для частного облака. Рассмотрим тезис о больших начальных инвестициях. Да, для создания частного облака надо купить оборудование и ПО, построить или арендовать ЦОД, установить ПО, создать облачную инфраструктуру и затем все это поддерживать. Это требует больших стартовых инвестиций. Но для того, чтобы получить сервис в публичном облаке, ничего этого делать не надо. Вы входите на портал публичного облака, выбираете сервис, оплачиваете его карточкой и тут же начинаете использовать. Цена небольшая, обычно оплата помесячная, инвестиции минимальные, старт почти мгновенный. Список примеров можно продолжить, но уже понятно, что перед разговором надо определиться, в каком облаке (публичном, частном, гибридном) и какие модели облачных сервисов (IaaS, PaaS, SaaS) [1] мы собираемся развертывать. В этой статье мы не будем говорить о публичных облаках, т к на сегодняшний день для нашей страны мне кажется более актуальны частные облака. Тут меньше проблем с безопасностью, контролируемостью, надежностью, интеграцией. Нет и ограничений функционала сервисов. А все преимущества облачной инфраструктуры сохраняются. Не будем мы говорить здесь и о SaaS (приложения как сервис). Это скорее тема для разработчиков тиражируемых приложений. Итак, говорим об IaaS и PaaS в частном облаке. Мы часто обсуждаем с заказчиками преимущества облачной инфраструктуры, делаем пилотные проекты, и в результате этих обсуждений выявили несколько наиболее популярных заблуждений (мифов) о частном облаке. Вот они: Перенос приложений в облако снижает их безопасность, надежность, управляемость, возможность интеграции, функционал облачных сервисов (например СУБД) ограничен Облако Oracle делается только на Exadata или Exalogic или HW от Oracle Облако должно быть от одного вендора Облако – это виртуализация Облака нужны только большим богатым организациям, стремящимся к инновациям (облака - это не для нас) Облако – это сложно, долго делать, дорого, требует полного изменения IT инфраструктуры Рассмотрим их подробнее. Миф 1. Перенос приложений в облако снижает их безопасность, надежность, управляемость, возможность интеграции, функционал облачных сервисов (например СУБД) ограничен Как уже упоминалось ранее, все перечисленные риски характерны для публичного облака. Если Вы создаете частное облако, то можете обеспечить тот же уровень безопасности, надежности, управляемости, который доступен в необлачной инфраструктуре. Практически все, что Вы можете обеспечить, развертывая базы данных и сервера приложений в своих ЦОД сегодня вручную, Вы можете обеспечить и при развертывании в частном облаке, только делаться это будет быстро и автоматически. Более того, можно легко повысить безопасность и надежность работы Ваших приложений в частном облаке, разбив приложения на группы по уровню требований к безопасности и надежности и затем стандартизовать требования к сервисам группы. Развернутые сервисы БД и серверов приложений не имеют ограничений по функционалу. Это те же БД и сервера приложений, которые Вы раньше разворачивали вручную. Применимы все опции, работают все функции. А поскольку это Ваш ЦОД, то руководство имеет полный контроль над его работой и может вмешиваться при возникновении нештатных ситуаций. Миф 2. Облако Oracle делается только на Exadata или Exalogic или HW от Oracle Большинство вендоров облачных продуктов реализует модель IaaS – инфраструктура как сервис (предоставление виртуального компьютера с помощью гипервизора) и предоставляет сервисы на платформе х86. Oracle реализует и модель IaaS и модель PaaS (платформа как сервис – базы данных и сервера приложений). Поэтому говорить о вычислительных платформах надо отдельно для IaaS и PaaS. Итак, IaaS от Oracle. Вы можете бесплатно реализовать его на любой х86 платформе, от любого вендора (включая конечно и компьютеры х86 от SUN). Кроме того, IaaS Oracle может быть реализован на RISC машинах от SUN с процессором SPARC (включая SuperCluster). Хорошо реализуется IaaS на инженерных системах ODA (Oracle Database Appliance) и Exalogic. Кроме того, специально для быстрого развертывания IaaS облака выпущен специальный аппаратно-программный комплекс OVCA (Oracle Virtual Computing Appliance), немедленно готовый для разворачивания IaaS. Т е заказчик может выбрать, что использовать – традиционные х86 компьютеры или специализированные инженерные системы. Можно использовать и то и то одновременно в одном облаке. Что касается Paas. Здесь тоже нет требования обязательного использования Exadata или Exalogic. Вы можете разворачивать облачные БД, сервера приложений и приложения Oracle на любом оборудовании, где Вы раньше разворачивали их вручную. Это и х86 компьютеры с различными ОС, и любые традиционные UNIX серверы от IBM, HP, SUN. Наиболее эффективно базы данных Oracle как сервис (DBaaS) можно развернуть на машине баз данных Exadata, а сервера приложений WebLogic с приложениями – на Exalogic. Преимущество Exadata для баз данных по сравнению с остальными вычислительными платформами только одно. Там есть менеджер ресурсов ввода-вывода, т е можно задать разные приоритеты использования операций ввода-вывода для разных БД. Кстати, Exadata может при установке автоматически конфигурироваться как зона DBaaS облака. Итак, инженерные системы и оборудование от SUN не являются обязательной платформой для облака Oracle. Миф 3. Облако должно быть от одного вендора Конечно хорошо бы делать все облако из продуктов от одного вендора. Например, Oracle позволяет и IaaS и DBaaS и FMaaS и SaaS сервисы развернуть в одном частном облаке. И управлять однородным облаком проще. Но часто заказчики хотят иметь IaaS от одного вендора (например, VMWare), SaaS от другого, ну а уж БД Oracle развертывать в DBaaS от Oracle. И это ничему не противоречит. Дело в том, что облако состоит из частей – зон (см рис 1.). А в зоне уже размещаются группы связанных компьютеров с единой системой хранения – пулы. Так вот, в одном облаке можно иметь зоны от разных вендоров. Например, развернуть 3 IaaS зоны – от VMWare, Microsoft, Oracle. И их виртуальные машины (и установленное в них ПО) могут успешно работать с СУБД Oracle, развернутой в четвертой зоне DBaaS Oracle. Для заказчиков сервисов все это выглядит прозрачно, т к они работают с единым порталом самообслуживания. Рис 1. Облако состоит из нескольких зон, в которых расположены пулы серверов Более того, изучение реализованных сегодня больших облаков (особенно национальных) показывает, что в их меню представлены продукты и виртуальные машины от нескольких вендоров, т е единый портал самообслуживания позволяет заказывать и использовать сервисы в разных зонах и от разных вендоров. Например, один из проектов, реализованных сегодня в России, использует в облаке СУБД Oracle как DBaaS и сервера приложений от Microsoft, разворачиваемые как IaaS через гипервизор HyperV. Конечно при таком разнородном облаке сразу встает вопрос – как им управлять? Тут есть 3 варианта. Либо для каждого вендора использовать его собственные средства управления (обычно они управляют своими продуктами лучше всех), а если сервисов в облаке много, то у каждой группы сервисов обычно имеются свои зоны и свои администраторы. Либо использовать инструмент одного из вендоров, который имеет дополнительные плагины для управления чужими гипервизорами. Например, стандартное средство управления облаком Oracle – Oracle Enterprise Manager умеет работать с плагином BlueMedora, который позволяет из того же интерфейса управлять машинами VMWare. Есть похожий продукт для VMWare и у продуктов управления облаком от IBM. И третий вариант – использовать универсальные средства управления облачными сервисами разных производителей. Сейчас это направление бурно развивается, идет стандартизация API. Среди таких универсальных инструментов можно назвать Nimbula Director, Rackspace OpenStack, Hotlink SuperVisor, Convert, IBM System Director, EMC Hybrid Cloud Solution и т д. Конечно возможности универсальных средств управления пока ограничены и поддерживают они ограниченное число вендоров. Поэтому скорее всего придется совмещать все 3 подхода. Миф 4. Облако – это виртуализация В определении облачной сервисной модели мы все руководствуемся определением, данным американским институтом стандартов NIST, где сказано, что облачная вычислительная модель имеет следующие характеристики: разделяемые вычислительные ресурсы, эластичность, учет использования ресурсов и оплата по факту использования, быстрое развертывание сервисов через Интернет по требованию, доступ к сервисам по сети. Нигде не сказано, как конкретно это должно реализовываться. Выделено только 3 сервисные модели – IaaS, PaaS и SaaS. Т е, если, например, заказчику нужен какой-то сервис (база данных, приложение и т д), то совсем не обязательно реализовывать этот сервис в виде виртуальной машины, содержащей требуемый продукт. Например, базу данных можно развернуть как виртуальную машину, содержащую БД – это IaaS, или как схему в существующей БД, или автоматически создать новую БД (или кластер БД) без виртуальной машины на имеющемся пуле компьютеров (это PaaS или его развитие для БД – DbaaS). Т е очевидно, что облачные вычисления не сводятся только к виртуализации машин, IaaS – это только одна из моделей реализации облака. Однако большинство вендоров (Amazon, Microsoft, Citrix, VMWare и т д) умеют реализовывать только виртуальные машины IaaS, все остальные сервисы разворачиваются внутри этих виртуальных машин и только на платформк х86. Более того, они разворачивают эти виртуальные машины только на платформе х86. Благодаря активности этих компаний у многих заказчиков сложилось мнение, что облако – это виртуальные машины на платформе х86. Это не так. Конечно IaaS – важная и неотъемлемая часть облака, но если нужны платформенные сервисы, такие как БД и сервера приложений, (а они являются неотъемлемой частью любой информационно управляющей системы, то их проще, быстрее и эффективнее разворачивать прямо на оборудовании (PaaS), а не как виртуальные машины. Т е в облаке должны быть как зоны IaaS, так и зоны PaaS. Предположим, Вы строите дом. Его конечно можно складывать из кирпичей или бревен, потом устанавливать сантехнику, отопление и т д. Но гораздо быстрее (и часто качественнее и дешевле) строить дом из готовых блоков (ванная, туалет, кухня, спальня и т д) (см рис 2). То же самое относится и к облаку. PaaS – это блочное строительство. Если в облаке нужны сервисы БД и серверов приложений, их лучше реализовать в виде PaaS. Задумайтесь, что Вам нужно – компьютер, в котором Вы будете вручную устанавливать и конфигурировать БД и сервера приложений, или сами эти сервисы? VS Рис 2. Строительство из кирпичиков против блочного строительства Если Вы не используете PaaS, а разворачиваете виртуалки с сервисами, то Вы получаете ПО, работающее внутри виртуальной машины. Этот подход имеет ряд недостатков. Во-первых, производительность. Ваше ПО работает не на железе, а внутри виртуальной машины, которая работает на этом железе, т е появляются дополнительные накладные расходы. В случае платформенного ПО производительность работы очень важна. Во-вторых, количество объектов управления и сложность управления. Если у Вас было 10 компьютеров с БД и Вы превратили их в 10 виртуальных машин с БД, Вам все равно придется управлять 10 виртуальными машинами и 10 БД. В случае PaaS, Вы можете развернуть эти 10 независимых БД внутри одной контейнерной БД Oracle 12c. При этом виртуальных машин нет, управлять надо только одним экземпляром СУБД (один бэкап, один STANDBY, один апгрейд, один объект для патчирования и управления и т д) вместо 10. Т е IaaS не упрощает администрирование. В-третьих – эффективность использования ресурсов (память, процессоры, диски). В случае 10 виртуальных машин Вы должны иметь место на дисках для дисков всех 10 машин и количество процессоров и памяти равное сумме числа процессоров и памяти этих машин (если они все могут работать одновременно). В случае PaaS – оперативной памяти, дисков и процессоров надо гораздо меньше, а при использовании для консолидации БД в облаке СУБД Oracle 12c c опцией Multitenant требуемый объем дисков, памяти и количество процессоров уменьшатся драматически [3]. В имеющихся тестахна одном компьютере помещается в 50 раз больше БД, чем при традиционном подходе. Если говорить про DBaaS, то мы получим также выигрыш в надежности и скорости клонирования баз данных. Да, в IaaS у некоторых вендоров существует режим синхронного поддержания онлайн копии работающей виртуальной машины. Но при реальной эксплуатации БД внутри такой машины объем изменений настолько велик, что быстрая синхронизация виртуалок (не знающих как работает СУБД) невозможна. В то же время режим автоматического поддержания синхронной или асинхронной резервной (Standby) БД для любых нагрузок и на любых расстояниях – типичный режим работы СУБД. В случае клонирования БД виртуальной машины Вам придется копировать все файлы машины. Для больших БД это займет очень много времени. В случае PaaS клоны создаются очень быстро, иногда мгновенно (при использовании механизма снэпшотов), т к копируются либо только файлы БД, либо только заголовки блоков файлов. Клонирование БД, особенно в облаке, - выполняется часто, т к регулярно нужны одинаковые БД для тестирования, разработки, отладки, резервирования и т д. А уж развертывание пустых БД – это вообще одна из основных функций DBaaS. И время такого разворачивания БД очень важно. Еще одним преимуществом PaaS перед IaaS является то, что PaaS позволяет развертывать базы данных и сервера приложений Oracle не только на платформе х86. Если Вам надо в облаке развернуть серьезные БД и сервера приложений на Unix серверах или инженерных системах – IaaS Вам не подойдет, придется использовать DBaaaS или FMWaaS. Как уже упоминалось выше, в облаке можно и нужно использовать и IaaS и PaaS. При заказе сервиса через портал самообслуживания пользователь часто даже не знает, как реализуется заказанный сервис. Надо использовать преимущества IaaS и PaaS в одном облаке. Так, IaaS хорош, например, для развертывания среды разработки на языках 3 поколения, получения чистого компьютера с ОС для дальнейшей установки программ, развертывания многослойных приложений для нескольких организаций/филиалов и т д. Миф 5. Облака нужны только большим богатым организациям, стремящимся к инновациям (облака - это не для нас) Часто перед общением с заказчиком, продавцы предупреждают нас "Пожалуйста не употребляйте в разговоре слова облака и облачные вычисления, у заказчика на них аллерия. Он абсолютно уверен, что никакие облака ему не нужны, вендоры уже достали его с этими облаками". Хорошо, мы конечно учитываем эти пожелания. Но когда начинаешь задавать заказчику следующие вопросы: Нужно ли Вам повысить эффективность использования оборудования? Нужна ли Вам более гибкая IT инфраструктура, позволяющая быстро адаптироваться к изменениям требований бизнеса, позволяющая быстро наращивать вычислительные мощности в моменты пиковой нагрузки? Нужен ли Вам детальный контроль использования различными службами и приложениями вычислительных ресурсов и возможность влияния на использование этих ресурсов? Нужна ли Вам возможность быстрого создания и клонирования баз данных, серверов приложений, вычислительных сред, компьютеров с ПО для разных пользователей? Нужно ли Вам обеспечить быстрое тестирование новых приложений и сервисов, тестирование новых версий и изменений? Будет ли интересен для бизнеса более быстрый вывод на рынок новых сервисов на основе IT? Стоит ли у Вас задача повышения эффективности работы администраторов БД и серверов приложений? Стоит ли перед Вами задача стандартизации IT инфраструктуры для сокращения затрат на IT? Рассматриваете ли Вы задачу консолидации баз данных, серверов приложений и приложений? Стоит ли перед Вами задача снижения рисков использования Вашей IT инфраструктуры? Нужно ли Вам повысить надежность работы приложений и их качество, без больших затрат на модернизацию IT? И Т Д оказывается что на часть из них, а иногда и на Все, он отвечает утвердительно. А ведь все эти задачи как раз и решает переход в частное облако. Поэтому не стоит бояться слова Cloud, а если что-то из приведенного Выше списка интересно для организации, ее IT структур или бизнеса, надо попробовать создать фрагмент облака и перенести туда одно-два приложения и убедиться, что при этом сильно облегчится решение перечисленных выше задач. Миф 6. Облако – это сложно, долго делать, дорого, требует полного изменения IT инфраструктуры Конечно перестройка всей IT инфраструктуры организации – долгий и сложный процесс, кроме того, не все приложения стоит переносить в облако. Есть методологии, определяющие, какие приложения проще всего и с наибольшей пользой можно перенести в облако. С них и надо начинать. Сегодня очень многие заказчики понимают необходимость перехода к облачной инфраструктуре в своих ЦОД, но не знают, с чего начать и боятся это делать. Чтобы развеять сомнения и доказать возможность создания облачной инфраструктуры и ее пользу лучше всего начать с пилотного проекта. В дальнейшем, созданное во время пилотного проекта небольшое облако явится основой для создания полноценного облака, т к в него можно постепенно переносить имеющиеся приложения и сервисы и создавать новые сервисы. Делать такой пилотный проект можно разными способами. Если у заказчика есть опытные ДБА, он может сделать все сам, документация хорошая и описывает все шаги. Можно при создании пилота привлечь специалистов Oracle (для консультаций или для выполнения всего проекта). Кроме того, партнеры Oracle имеют опыт создания облака Oracle. Сроки выполнения пилотного проекта зависят от его объема и опыта исполнителей. При наличии оборудования и согласованного технического задания опытные специалисты реализуют пилотное облако за 2 – 3 недели (рекорд – 1 неделя). Если заказчик желает реализовать в облаке IaaS, DBaaS и FMaaS, то архитектура стенда будет выглядеть как на рисунке 3. В ней предусмотрена управляющая машина с системой создания и управления облаком (Oracle Enterprise Manager – OEM) и три зоны – для развертывания виртуальных машин (IaaS), для развертывания баз данных Oracle (DBaaS) и для развертывания серверов приложений Oracle WebLogic (FMaaS). В изображенной на рисунке архитектуре одного из POC также добавлена зона для развертывания кластеров БД Oracle и компьютер для системы управления доступом (IDM). Если в пулы включать по 2 компьютера (для демонстрации онлайновой миграции виртуальных машин, создания кластеров БД и кластеров WebLogic, то минимальное число компьютеров для такого пилота равно 7. Кроме того, нужна система хранения, доступная компьютерам облака. При обсуждении технического задания на пилотный проект необходимо ответить на следующие вопросы: Для IaaS – на какой платформе будем строить IaaS – x86, OVCA, SPARC, ODA; какие ОС и ПО будут в развертываемых виртуальных машинах; нужно ли реализовывать Live Migration (онлайновый переезд виртуальных машин) и сборки (assembly) – разворачивание группы взаимосвязанных виртуальных машин?. Рис 3. Архитектура стенда для пилотного проекта облака Для FMaaS - на какой платформе будем делать FMaaS – х86, UNIX серверы, Exalogic; разворачивать WebLogic в кластере или без кластера; разворачивать WebLogic с Java приложениеми или добавлять их позже? Для DBaaS - на какой платформе будем делать DBaaS – x86, UNIX серверы, ODA, Exadata; будем развертывать БД в виртуальной машине, на голом железе, в контейнерной БД или просто развернем схему в БД; будем ли использовать механизм мгновенного клонирования (snapshots); как будем делать БД – пустую, полную из бэкапа, полную из export файла, из копии существующей БД; создавать отдельную БД или кластер БД; нужно ли маскировать и урезать промышленную БД, на основе которой разворачиваются новые БД в облаке? Если мы планируем использовать механизм быстрого клонирования, то это накладывает определенные ограничения на выбор системы хранения. Сегодня это возможно сделать на ZFS Storage Appliance, NetApp, Solaris ZFS File System и вскоре на Oracle ASM. Позднее будут поддерживаться и другие системы хранения. После окончания создания прототипа облака заказчик может начать добавлять в стандартный портал самообслуживания свои собственные сервисы, а также написать свой собственный портал самообслуживания и разработать систему тарификации потребляемых услуг. Постепенный переход в облако с поэтапным переносом туда существующих приложений и сервисов и с использованием высвобождающегося оборудования и лицензий на ПО позволяют ускорить, упростить и удешевить переход в частное облако и максимально быстро начать использовать преимущества гибкой облачной IT инфраструктуры. Литература М Ривкин. Как создаются облака//Открытые системы, 2012, N 4 М. Ривкин. Облачные вычисления. Как создать облако от Oracle http://mrivkin.narod.ru/Publ/Mark_cloud_art.doc М. Ривкин, И. Мельников. СУБД для облаков //Открытые системы, 2013, N6 http://mrivkin.narod.ru/Publ/Mark_12c_NF_art.7z

Похожие:

	Облачные вычисления. Как создать облако от Oracle Термин “облачные... Почти каждую неделю появляются новые статьи, книги, презентации об облачных вычислениях – новой сервисной модели предоставления вычислительных...		Реферат на тему «История развития вычислительной техники» Слово «компьютер» означает «вычислитель», т е устройство для вычислений. Потребность в автоматизации обработки данных, в том числе...
	Книга и моя жизнь наполнены двумя моими увлечениями В течение 25 лет я был увлечен мобильными компьютерами. В мире высоких технологий Силиконовой Долины я известен как зачинатель двух...		Методические указания для студентов специальностей: 240304 «Технология... Кроме того, в инженерном режиме появляются также возможности определения порядка вычислений при помощи скобок, осуществления побитовых...
	Лабораторная работа №1: Создание баз данных В этой утилите можно выполнить типовые задачи обслуживания баз данных, такие как резервирование и восстановление. Здесь можно настраивать...		Нашего классного часа сегодня Найти себя. Понятно, что речь пойдёт... Средние учебные заведения, училища, работа такие маршруты ждут тех, кто уже сделал свой выбор. Для остальных будет еще 2 года, чтобы...
	Руководство Oracle На них не следует полагаться при принятии решений относительно закупок. Разработка, выпуск и график поставки функций или функциональности,...		«Формирование у младших школьников икт компетенций на основе внедрения... Икт компетенций на основе внедрения в учебно-воспитательный процесс сетевых облачных технологий Google
	Использование программы Comphep для распределенных вычислений процессов... ...		Математико-механический факультет Кафедра системного программирования... К ним можно отнести сегодня разве что db2 udb корпорации ibm и Oracle. Оба продукта обладают развитой функциональностью, необходимой...
	Пояснительная записка Кафедра пмиК Файловый менеджер для операционной системы Android с поддержкой облачных сервисов		1. Вводные замечания История социологии религии как дисциплины, определившей... Э. Дюркгейма и М. Вебера. После первой мировой войны центр ее развития переместился из Европы в США. В россии социологии религии...
	1. Вводные замечания История социологии религии как дисциплины, определившей... Э. Дюркгейма и М. Вебера. После первой мировой войны центр ее развития переместился из Европы в США. В россии социологии религии...		Консультация "О летнем отдыхе детей" Поэтому очень важно, чтобы родители с наибольшей пользой распорядились этим драгоценным временем. Вместе с тем возникает немало вопросов,...
	Консультация "О летнем отдыхе детей" Поэтому очень важно, чтобы родители с наибольшей пользой распорядились этим драгоценным временем. Вместе с тем возникает немало вопросов,...		Интервью с Михаилом Каравановым, генеральным директором компании... В2В-рынках, делая акцент на изучении удовлетворенности потребителя, уделяем внимание построению системы коммуникаций в В2В-сфере,...