PlanetMysql.ru - информация о СУБД MySQL » devops

Devops in Munich

Kris Buytaert — Tue, 01 May 2012 19:02:30 +0000

Devopsdays Mountainview sold out in a short 3 hours .. but there's other events that will breath devops this summer.
DrupalCon in Munich will be one of them ..

Some of you might have noticed that I`m cochairing the devops track for DrupalCon Munich,
The CFP is open till the 11th of this month and we are still actively looking for speakers.

We're trying to bridge the gap between drupal developers and the people that put their code to production, at scale.
But also enhancing the knowledge of infrastructure components Drupal developers depend on.

We're looking for talks both on culture (both success stories and failure) , automation,
specifically looking for people talking about drupal deployments , eg using tools like Capistrano, Chef, Puppet,
We want to hear where Continuous Integration fits in your deployment , do you do Continuous Delivery of a drupal environment.
And how do you test ... yes we like to hear a lot about testing , performance tests, security tests, application tests and so on.
... Or have you solved the content vs code vs config deployment problem yet ?

How are you measuring and monitoring these deployments and adding metrics to them so you can get good visibility on both
system and user actions of your platform. Have you build fancy dashboards showing your whole organisation the current state of your deployment ?

We're also looking for people talking about introducing different data backends, nosql, scaling different search backends , building your own cdn using smart filesystem setups.
Or making smart use of existing backends, such as tuning and scaling MySQL, memcached and others.

So lets make it clear to the community that drupal people do care about their code after they committed it in source control !

Please submit your talks here

PlanetMySQL Voting: Vote UP / Vote DOWN

Devops in Munich

Kris Buytaert — Tue, 01 May 2012 19:02:30 +0000

Devopsdays Mountainview sold out in a short 3 hours .. but there's other events that will breath devops this summer.
DrupalCon in Munich will be one of them ..

Some of you might have noticed that I`m cochairing the devops track for DrupalCon Munich,
The CFP is open till the 11th of this month and we are still actively looking for speakers.

So lets make it clear to the community that drupal people do care about their code after they committed it in source control !

Please submit your talks here

PlanetMySQL Voting: Vote UP / Vote DOWN

CAOS Theory Podcast 2012.04.20

The 451 Group — Fri, 20 Apr 2012 19:10:50 +0000

Topics for this podcast:

*OpenStack, Amazon, Eucalyptus and Citrix engage in open cloud warfare
*Microsoft spins off new company for openness
*Updates on automation players Puppet Labs and Opscode with Chef
*Percona turns attention to MySQL high availability
*Open APIs as the fifth pillar of modern IT openness

iTunes or direct download (28:42, 4.9MB)

PlanetMySQL Voting: Vote UP / Vote DOWN

How MySQL Innodb works and how realestate.com.au configures their databases

Trent Hornibrook — Wed, 28 Mar 2012 10:01:16 +0000

I gave a lightning talk on MySQL Innodb and how realestate.com.au configures their databases to the DevOPS Melbourne meetup last night.

My slides can be found here.

Simply some take aways are

Use Innodb for everything (unless another engine is appropriate)
Having the working set in bufferpool makes MySQL Innodb fast by eliminating those foreground randrom reads of tablespace
Use a RAID controller with BBU and write back cache for transactional log performance

Thanks To Evan Bottcher for owning and organising the meetup!

PlanetMySQL Voting: Vote UP / Vote DOWN

Open APIs are the new open source

The 451 Group — Tue, 14 Feb 2012 18:08:58 +0000

We’ve seen the rise of open source software in the enterprise and also beyond the IT industry, but the real keys to openness and its advantages in today’s technology world — where efficient use of cloud computing and supporting services are paramount — exist in open application programming interfaces, or APIs.

Open source software continues to be a critical part of software development, systems administration, IT operations and more, but much of the action in leveraging modern cloud computing and services-based infrastructures centers on APIs. Open APIs are the new open source.

Read the full story at LinuxInsider.

PlanetMySQL Voting: Vote UP / Vote DOWN

CAOS Theory Podcast 2012.01.20

The 451 Group — Fri, 20 Jan 2012 20:24:49 +0000

Topics for this podcast:

*Hadoop v1.0 and year ahead
*Oracle-Cloudera deal for more Hadoop
*Oracle’s ‘Sun spot’ with Solaris
*Open Source M&A outlook for 2012
*Our new MySQL/NoSQL/NewSQL survey

iTunes or direct download (28:49, 4.9MB)

PlanetMySQL Voting: Vote UP / Vote DOWN

CAOS Theory Podcast 2011.11.11

The 451 Group — Fri, 11 Nov 2011 19:27:40 +0000

Topics for this podcast:

*Continuent extends MySQL replication to Oracle Database
*CFEngine updates server automation software
*Devops moving mainstream
*Neo Technology integrates with Spring
*451 CAOS report from Hadoop World

iTunes or direct download (26:56, 4.6MB)

PlanetMySQL Voting: Vote UP / Vote DOWN

Why generalists are better at scaling the web

Sean Hull — Tue, 25 Oct 2011 17:41:18 +0000

Recently at Surge 2011, the annual conference on scalability and performance, Google's CIO Ben Fried gave an illuminating keynote address. His main insight was that generalists are the people that will lead engineering teams in successfully scaling the web.

In a world where the badge of Specialist or Expert is prized, this was refreshing perspective from an industry bigwig. As tech professionals, or any professional for that matter, we don't welcome the label of generalist. The word suggests a jack-of-all-trades and master of none. But the generalist is no less an expert than the specialist. Generalists can get their hands greasy with the tools to fix bugs in the machine but they especially good at mobilizing the machine itself; with their talents of broad vision, and perspective they can direct an entire team to accomplish tasks efficiently. This ability to see big-picture can not be underestimated especially during times of crisis or pressure to meet targets. For a team to scale the web effectively, you're going to need a good mix of both types of personalities.

Picking out the potential generalist

Startups wanting to achieve scalability are face with huge pressure to do more with limited budgets. In bringing on new engineers, they must hire people who have the programming skills to realise their big idea. Ideally these programmers should also have some architectural vision, a knowledge of web operations, and performance as that application becomes popular. And what of maintaining that large infrastructure as it grows?

So the question for a startup is how do you spot or hire generalists? In the book, REWORK by Jason Fried and David Heinemeier Hansson, the authors emphasize good writers and good teachers. Their point is that in order to teach an idea or concept you have to understand it thoroughly and be able to step into someone elses shoes in order to explain it from their vantage point.

This is in large part the skill that Ben Fried was speaking about at Surge. To borrow his method of using "Disaster Porn" as a way to illustrate a point, we have a story of our own.

Our own disaster porn

About five years ago we worked for a firm who was faced with ongoing challenges of growth. Their user base was growing by 25%-50% per quarter but they were suffering from outages because of that growth. What's more one of their top engineers was leaving to join another company. They took the opportunity to bring us on board to assess the entire infrastructure.

We looked over the architecture and were surprised at every turn. Although they had a lot of engineers on staff, they were all tasked with building features, and responding to ongoing business requirements. None were given any operations responsibilities. There was a very obvious lack of leadership. so you can imagine how this turned out to be a recipe for a fine mess. One day we'd see new servers being added at random, another day we'd witness haphazard decisions with what technologies to use or what what versions of frameworks to adopt. In effect, each engineer was making decisions without considering the consequences on the whole.

The infrastructure wound up being built on two different webserver platforms, three - count 'em - three different programming languages and frameworks, and three MySQL databases scattered about on different machines. After a few hours discussing the architecture with the team, I put together a plan that framed the architecture around three simpler tiers. Two included the standard load balanced webserver tier, and backend database tier, and then a third to manage batch jobs and building static assets and media files.

A generalist solution

Our push then was to standardize on one type of webserver, one version of each language stack, and consolidate all the databases into one instance. This huge simplification meant that they could add replication to the database tier, eliminating single points of failure, providing redundancy for all business services. This in itself was a major achievement. We left them with some major problems solved, while offering a new direction, and a better handle on the remaining challenges. What the company had lacked was not engineering know-how, but rather a generalist's perspective. The engineers had focused too much on immediate tasks, locked on detail, but losing sight of the big picture.

As more companies move their applications to the cloud, some carefully and some not, we anticipate many more disaster scenarios such as these. This speaks strongly to the rising cult of DevOps and its effort towards broader skills and collaboration among both developers and operations teams. The good thing to come out of it is that cleaning up messes such as these will force us to hone our strategic thinking and organizational skills, possibly making generalists out of many more of us.

PlanetMySQL Voting: Vote UP / Vote DOWN

CAOS Theory Podcast 2011.09.30

The 451 Group — Fri, 30 Sep 2011 19:16:51 +0000

Topics for this podcast:

*Cloud M&A potential around OpenStack
*Oracle’s commercial extensions for MySQL
*Puppet Labs rolls out Enterprise 2.0, hosts PuppetConf
*Basho bolsters Riak distributed data store in NoSQL race
*Our latest special CAOS report, ‘The Changing Linux Landscape’

iTunes or direct download (25:59, 4.4MB)

PlanetMySQL Voting: Vote UP / Vote DOWN

Paying Attention Pays Off

Robert Treat — Mon, 15 Aug 2011 14:57:24 +0000

I often run my ops like I take care of data; a bit overzealously. Case in point, when setting up a new database, I like to throw on a metric for database size, which gets turned into both a graph for trending, but also an alert on database size. Everyone is always on board with trending database size in a graph, but the alert is one people tend to question. This is not entirely without justification.

On a new database, with no data or activity, deciding when to alert is pretty fuzzy. When we set up a new client within our managed hosting service, I usually just toss up an arbitrary number, like 2GB or something. The idea isn't that a 2GB database is a problem, it's that when we cross 2GB, we should probably take a look at the trending graph and do a projection. Depending on how things look, we'll bump up the threshold on the alert to a new level, based on when we think we might want to look at things again. For example, in this graph we take a month long sample, and then project it out for three months. We can then set a new threshold somewhere along that line.

While this is good for capacity planning, there's more that can be gained from this process. The act of alerting forces us to pay attention. And if we get notices before our expectations, we go back in and re-evaluate the data patterns. Of course, some times people will question this. Getting a notice that your database has passed 4GB can seem pointless when you have 100+ GB of free space on your disks. And besides, isn't that what free space monitors are for?

Here is a graph of another of our clients database growth. Their data size is not particularly large (don't confuse scalability with size; it doesn't take a large database to have scalability issues), but what's important is that we kept getting notices that the size was growing, and when talking with the developers, no one thought it should be growing at nearly this rate. Eventually we were able to track down the problem to purging job that had gone awry. Once that was fixed, the growth pattern leveled off completely (and the database size returned to the tiny amount that was expected!)

PlanetMySQL Voting: Vote UP / Vote DOWN